Updates from January, 2020 Toggle Comment Threads | Keyboard Shortcuts

  • penguin 21:28 on 2020-01-25 Permalink | Reply
    Tags: check_mk, , ,   

    Check MK container/k8s deployment 

    In the company everybody seems to love Check MK. Me? Not so much, but a better alternative costs time and effort, both resources we don’t really have right now. Yet there’s a positive thing about it – because there’s an official docker container. Since I already coded a helm chart for stateful single container softwares (which I personally find super useful), I just wrote a Check MK YAML and installed it on my K8S cluster.

    And then nothing worked. Turns out, Apache – which is used in that very strange “Open Monitoring Distribution” which Check MK seems to have been at one point – has a slightly sub-optimal configuration for running in a container behind a load balancer using cert-manager.

    In short, you connect to the load balancer using “cmk.my.domain”, and it redirects you to the container port, which to itself is “https://cmk.my.domain:5000/” and just wrong. Which brings me to the question if anybody has ever tried to run the Check MK container in a k8s cluster or behind a load balancer, which brings me to the question that I’d rather use software which actively embraces that, which brings me to the question WHICH ONE?!? which brings us back to “no resources, no time”.

    So, bad luck, Check MK it is. But what about the bug? Reporting it you get an email “DONT CALL US – WE CALL YOU (and we probably won’t)“, with a ticket ID but no link. So probably no help here. So I “forked” the container, fooled around with it, and found a solution. The “fixed” container is now available on docker hub (sources on GitHub) and running nicely in our internal cluster. Let’s see which hidden bugs I have introduced 😉 . The stasico-Helm-YAML file I used to deploy Check MK in K8S is also available.

    TL;DR
     
  • admin 12:22 on 2019-08-31 Permalink | Reply
    Tags: azure, functions, javascript, serverless   

    The 6 ways of returning data from an Azure Function 

    Why have one if you can have many? Well, beats me, but I thought I’d collect them here so I have my personal reference. Disclaimer: This is only for JavaScript based functions (most of the examples on the MS pages are C#).

    So, most of them have to do with the file function.json  file:

    {
        "bindings": [{
            "type": "httpTrigger",
            "name": "req",
            "and": "so on ..."
        }, {
            "type": "http",
            "name": "thisIsAnOutputBinding",
            "direction": "out"
        }, {
            "type": "someOtherType",
            "name": "anotherBinding",
            "direction": "out"
        }]
    }

    More precisely, with the “out” type binding that is defined in the 2nd “bindings” object. The “out” binding has a “name” property, which is basically relevant for all of the methods.

    !!!!! WARNING !!!!! – It seems the name of the binding property must be camelCase. At least I consistently get “invalid binding” errors when I use snake_case

    Method 1 – context property

    The context object has one property per defined “out” binding. So if our property is named “thisIsAnOutputBinding”, our result property is context.thisIsAnOutputBinding , or as MicroSoft puts it:

    Outputs (bindings of direction === “out” ) can be written to by a function in a number of ways. In all cases, the name property of the binding as defined in function.json corresponds to the name of the object member written to in your function.

    Simply put, you just assign the value to a context  member and you’re done:

    module.exports = function(context, req) {
        context.thisIsAnOutputBinding = {
            "my": "return value",
            "in this case": "an object"
        }; 
        // contect.done() is only needed for synchronous functions context.done();
    }

    Source here.

    Method 2 – return an object (async functions only)

    With the bindings given above, you can assign the values to the context property, but you can also return an object whose keys correspond to the binding names:

    module.exports = async function(context) {
      return { thisIsAnOutputBinding: 42, anotherBinding: 43 };
      // of course, instead of 42/43 you can put any js object here.
    };
    

     

    Source here.

    Method 3 – using context.bindings

    This is basically a variant of method 1. Why does it exist? No one knows. Apparently the context object has a .bindings  property, which in turn again has properties which name-match the defined out bindings. So this is another possibility, and I think the return  is unnecessary:

    module.exports = async function(context) {
      let retMsg = "Hello, world!";
      context.bindings.thisIsAnOutputBinding = {
        body: retMsg
      };
      context.bindings.anotherBinding = retMsg;
      return;
    };
    

    Source here.

    Method 4 – using context.done()

    If you’re using a sync method, you can’t return an object, but you can call context.done(err, obj) .

    module.exports = async function(context) {
      context.done(null, {
        thisIsAnOutputBinding: { text: "hello there, world", anotherBinding: 42 }
      });
    };
    

    Source here.

    Method 5 – just return it already (only async functions)

    Probably someone said “Well, if I only have one output binding, why should I explicitly address it?”, which is a valid thought. So another way to return data was invented.

    For this the configuration in function.json looks a bit different:

    {
      "bindings": [
        { "type": "someType", name: "req", direction: "in" },
        { "type": "someOutType", direction: "out", name: "$return" }
      ]
    }
    

    You have to set exactly one “out” type binding, and the name must be “$return”. Then you can do this:

    module.exports = async function(context, req) {
      return "woohooo!!";
    };
    

    Source here.

    Methods 6 – special for http outputs

    You thought we were done? Noooooo. For http methods, you can diretly return the body object which is then used to create the body

    // actually NO IDEA if this works sync, async or both
    // my guess is: sync, because "context.done() is implicitly called"
    module.exports = async function(context, req) {
      rv = { body: "<html/>", status: 201 };
      context.res.send(rv);
    };
    

    Source here.

    Summary

    Let’s just say it’s a mess, and too many ways ruin the map.

    It works though.

     
c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel