I want to implement custom metric API server to use with HPA. we have proprietary monitoring system that have client library in C# but all the implementation i saw online are in Go.
Is there a definition of REST API (request and response) that the HPA call? or this can be only in Go (for some reason)?
I can use this to create a proxy server between Go and my C# server but i rather go straight to my server from HPA
types.go files are the source of truth for Kubernetes API definitions. All other definition formats are generated from these files. You can find files with definitions of custom metrics API here:
v1beta1
v1beta2
Script to generate swagger API definitions can be found here but is probably not worth the trouble since the API is so simple.
"Is there a definition of REST API (request and response) that the HPA
call? or this can be only in Go (for some reason)?"
From what I was able to find the original API definitions in types.go are in GO code. For some APIs other API definitions are available, but they're all generated from types.go files and this particular API doesn't have any other definitions pre-generated because it's not an official part of k8s APIs. I'm not 100% sure but it certainly looks like currently GO is the only way to go.
Related
I am using a Logic App for which I need to create a custom connector. This connector depends on a web service, for which I am trying to add using wsdl definition.
Now If I provide the url, it needs authentication, which I am not able to provide via this UI. I can see the parameters can be provided while using it in the logic app. However it fails to pull the services and hence not creating the definition for the connector
I tried downloading the wsdl and adding here as a file, but the schema have xs import tags, because of which its failing again. And as per this answer, I can not replace it with actual schema.
<xs:import namespace="http://some.name/" schemaLocation="./path/to/it.xsd"/>
Is there a way that I do not need to provide the custom connector definition manually and make it work using wsdl, as it contains a lot of endpoints and it would be too much to add all actions and triggers manually. Plus it would be also reference for me if needed in future for such scenario
You may try this if the services are accessible over the internet, then you call service endpoint over HTTP or HTTPS from azure logic apps. This article will help you with details steps to be followed: https://learn.microsoft.com/en-us/azure/connectors/connectors-native-http
If it is not accessible over the internet then this article will help with step by step process: https://learn.microsoft.com/en-us/azure/logic-apps/logic-apps-gateway-connection
Before you can access data sources on premises from your logic apps, you need to create an Azure resource after you install the on-premises data gateway on a local computer. Your logic apps then use this Azure gateway resource in the triggers and actions provided by the on-premises connectors that are available for Azure Logic Apps.
Also check this
I would like to be able to call Powershell scripts using a REST API. (Please note that I am describing the _opposite_ of calling a REST API from Powershell.) Are there any prebuilt API gateways that support this use case? I've looked at Ocelot, but it currently only acts as a gateway to other REST APIs. Ideally I would simply design my Powershell script functions to follow a defined interface pattern, put the files into a defined directory, and the API gateway would either immediately make those functions available as REST API calls or with minimal configuration.
EDIT: To clarify, I am looking for something self hosted, not cloud based. I haven't found anything yet that is exactly what I need, I may create something myself.
You can try AWS Lambda and API gateway integration.
Here is an example: https://aws.amazon.com/blogs/developer/creating-a-powershell-rest-api/
Amazon offer 12 month free tier plan for this.
A couple of options. If you are on Azure you could expose your Powershell Scripts through Azure Automation :
https://learn.microsoft.com/en-us/azure/automation/automation-webhooks
That'd be a lightweight way of having your scripts enabled through a HTTP POST scenario.
You could also combine or mix it with adding API Management in front to support various scenarios (adding GET/PUT/DELETE support e.g.) or even automate or proxy more things. API Management could of course also be automated.
https://azure.microsoft.com/en-us/services/api-management/
You could also create a folder structure with modules & sub-functions and create a full REST API by using Azure Functions with PowerShell:
https://learn.microsoft.com/en-us/azure/azure-functions/functions-reference-powershell
The latter would also be able to execute in containers & in the supported Azure Function
runtimes.
I want to create a SOAP service in micronaut using kotlin. I can not find information about how to do this. Annotations like #WebService are not being hosted as an endpoint.
I've successfully exposed the result to a rest endpoint.
I found information about how to implement a soap client in micronaut.
I succeeded in publishing the endpoint using endpoint.publish(..., ...), but I want to use the built-in netty-server, and perhaps built-in annotations, to prevent having to expose my services in a different class.
I don't think you would use micronaut http client for that. Look at apache axis 2 and see how you can use that.
I have a very basic setup: APIM + SF with WebAPI Stateless Service (Kestrel). Just trying to make this POC work. Unsuccessful so far... :(
Following the available instructions I got to the point, where I am having problems with the APIM inbound policies...
What am I supposed to use for the backend-id?
Besides the "servicefabric" one (from examples), I have tried probably all of the options from my "service fabric" instance metadata. It keeps coming back to me with:
"Backend with id 'whatever-I-put-in-here' could not be found."
I would really appreciate if someone could shed some light into what exactly is meant by backend-id=""!
Thanks,
Peter
The backend-id has to reference a "backend resource" that has been created via the API Management API (or deployment template) as there currently is no UI to create these backend resources. In the deployment template pointed to by the article the definition of the backend resource is here:
https://github.com/Azure-Samples/service-fabric-api-management/blob/master/apim.json#L162
You can use this API call to list the existing backends for your service:
GET https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.ApiManagement/service/{serviceName}/backends?api-version=2017-03-01
https://learn.microsoft.com/en-us/rest/api/apimanagement/backend/listbyservice
I am building REST APIs with MicroServices, which means I have different services for providing different resources. Suppose I have below services:
ServiceA is providing resources resourcesA and resourcesA1 with below URLs
https://my-internal-endpoint-for-serviceA/resourcesA
https://my-internal-endpoint-for-serviceA/resourcesA1
ServiceB is providing resources resourcesB and resourcesB1 with below URLs
https://my-internal-endpoint-for-serviceB/resourcesB
https://my-internal-endpoint-for-serviceB/resourcesB1
Now, I want to manage them in Azure API Management. To publish them (by importing the Swagger document from services), API Management portal need an API path for publishing. So, serviceA and serviceB can be published as below:
https://my-api-azure-api.net/serviceA/resourcesA
https://my-api-azure-api.net/serviceA/resourcesA1
https://my-api-azure-api.net/serviceB/resourcesB
https://my-api-azure-api.net/serviceB/resourcesB1
But to be more resources based API management, I am expecting the published APIs to be more like below:
https://my-api-azure-api.net/resourcesA
https://my-api-azure-api.net/resourcesA1
https://my-api-azure-api.net/resourcesB
https://my-api-azure-api.net/resourcesB1
Unfortunately, API management does not allow me for pubshing 2 APIs (serviceA and serviceB) to same path (root path in this case). I don't want to put the service name (or something equivalent) in the URL path as the service name is something duplication of the resource name provided by it. How do I workaround this?
The Azure API Management Policies can help you here, in particular the control flow with the ability to forward requests. The documentation is here: https://learn.microsoft.com/en-us/azure/api-management/api-management-policy-reference
I would approach this by setting up the resources as a single API, by adding one via swagger and then adding in the other services to this one to make it complete (as you want it to appear as a single complete service). Once this is in place you are then free to apply the policies.
Note: you may have to expand the resource path in the following way
https://my-api-azure-api.net/mynewservice/resourcesA
https://my-api-azure-api.net/mynewservice/resourcesA1
https://my-api-azure-api.net/mynewservice/resourcesB
https://my-api-azure-api.net/mynewservice/resourcesB1
Maybe the answer to this question can help:
How to chain APIs using Azure API management
You can use the same policy to map several operations of the same API in API Management to different backend APIs.
But in general all APIs are exposed as <myGateway>.azure-api.net/<myApi>/<myOperation>.