I would like to know if MLflow currently does support any kind of customization of it's scoring_serving that would allow the ability to register new endpoints to the published Rest API.
By default the scoring server provides /ping and /invocations endpoint, but i would like to include more endpoints in addition to those.
I've seen some resources that allow that kind of behaviour using custom WSGI implementations but i would like to know if extension of the provided mlflow scoring_server is possible in any way, so the default supporty provided by mlflow generated docker images and the deployment management is not lost.
I explored existing official and unofficial documentation, and explored existing github issues and the mlflow codebase in it's github repository.
Also i've explored some alternatives such as using custom WSGI server configuration for starting the Rest API.
Any kind of resource/documentation is greatly appreciated.
Thanks in advance.
Related
When one creates an ASP.NET Core Web API in Visual Studio 2022, and tests it locally, one gets a convenient Swagger page built upon an OpenAPI definition, to test all HTTP endpoints.
However, when deployed and trying to access {path-to-api}/swagger, it returns a 404 Not Found error, even while on localhost, when both the API and the database is sitting on my own machine. Even if the database is in the Azure cloud, for that matter, it also works, if I put the Azure SQL Database connection string into appsettings.json.
So is there a way to achieve this, preferably without too much hassle? Or am I wrong in wanting this, do developers mostly test their APIs locally? Because I want the Swagger API online only for testing.
The problem is getting and using the swagger functionality into the cloud. Is it possible and good practice?
If you look at the startup, you will notice that the swagger is only loaded during a development session via an if check. Commenting that out, or expanding it based on evironment, will allow a published version to generate the page on the target host.
if (app.Environment.IsDevelopment())
{
app.UseSwagger();
app.UseSwaggerUI();
}
I generally do that for first publishes or to Dev/Test environments to see it running. Once it is not needed, I un-comment it back in.
Also it may be actually viable (turned on) in Dev or UAT server because one is also publishing the open api it to APIM (Azure api manager), which takes the api and generates its own development environment; away from an initial publish.
Also once published, it is not the default page, one still has to path to it such as .../swagger/index.html.
I'm aborting this mission to deploy the Swagger interface to Azure along with my API. It's bad security practice to make the HTTP request methods so visually available to all. So the answer to my question do developers mostly test their APIs locally, is apparently yes.
I wondered if I should remove the question, but I would like to make it still stand, in case anyone else is contemplating about doing the same thing - exposing an API online with the Swagger UI.
I have a single screen desktop application developed in Java. It is a tool to convert files, given a file in .abc format, the tool converts it to .xyz format. Basically the tool works offline and acts as a translator to convert file from one form to another.
So now, to improve the infrastructure, there are discussions to move the tool to Kubernetes or to provide REST services for the file conversion. I completely have no idea about the containers nor the REST APIs as I am a front-end developer.
More about the tool, as I told earlier, the tool is a single page application, very light doing very minimal job, totally used by 200 users approximately. So, this being the shape and size of the application, which one would be the best approach to go with and why? Basically, I am looking for a short evaluation report of Kubernetes vs REST service and architecture recommendation with reasons.
Currently your application is a standalone application which is quite an old concept.
I can mention high-level changes needs to be done when your file conversion logic would be exposed over Rest Api in Kubernetes world.
you can go through one by one following mentioned areas to get a better understanding design-wise:
java code would be a backend code and its public methods that take inputs from UI actions will be exposed over rest API.
There are multiple rest API's (jersey, rest easy, etc or spring/spring-boot framework also provides rest API support) that you can go through any of them to get an understanding.
once your backend is exposed over the rest API then it needs to be containerized means your backend will be running under the container. Can go through docker documentation and can build one sample containerized app. There is huge material present in this area.
once your backend is containerized then it will be installed in a Kubernetes cluster
Kubernetes is basically a container orchestration tool and it's quite a wide thing. you can through its official documentation for basic understanding.
SPA will be running on a client machine like today also you are able to launch from your desktop but it will communicate with the Kubernetes cluster where your application is presently packaged in a container.
References:
docker :
https://docs.docker.com/
Kubernetes :
https://kubernetes.io/
Kubernetes OpenAPI specification is hosted here.
https://github.com/kubernetes/kubernetes/tree/master/api/openapi-spec
Additionally, various client APIs for the Kubernetes is provided here:
https://kubernetes.io/docs/reference/using-api/client-libraries/
Using the OpenAPI specification, I am able to generate the server code, which provides the REST services. However, the applications using these K8s client APIs (written in either language - Go, Java, etc.) do not use these REST API directly.
My objective is to mock the K8s server to use in the test automation and build a controlled environment to create various test scenarios.
Is there any ready-to-use Kubernetes mock available? If not, how we can interface the client APIs with the above OpenAPI generated REST server? This way, the applications shall continue to use the client APIs but internally, they will be communicating with the mocked K8s server and not the real one.
Please help with the options.
.
Not really a direct answer to your question, but most solutions i have seen implemented are not trying to mock the k8s API but are really using it through either k3s (from rancher labs) or KinD project (official way)
You then connect to it like a normal kubernetes cluster
I have my code in Git repository. I am using UDeploy to deploy my code into MarkLogic environment. I can able to move all my modules successfully but facing two problems
1. Creating New indexes
2. REST endpoint creation
Please let me know if there is anyway to implement these two
For creating indexes, I have tried to do it using API functions(admin:database-range-element-index()) and I have successful in that part. But is there any way to do it from UDeploy or DevOps.
For register REST endpoint I couldn't able to find anyway to try.
Have you looked at MarkLogic's REST Management APIs - https://docs.marklogic.com/REST/management. In particular, see if https://docs.marklogic.com/REST/POST/manage/v2/databases will help you create indexes via REST management APIs.
The most common way to deploy MarkLogic code & configuration is ml-gradle, a plugin to the widely used gradle tool. ml-gradle uses MarkLogic's Management API, mentioned by Ganesh, and is scriptable.
I have a test Hyperledger Fabric running in the IBM Cloud, with the IBM Blockchain Application Service. I also have a kubernetes cluster running the Hyperledger Composer REST Server. Everything works great, but how do I extend the REST api with some custom api's?
The documentation mentions being able to use the swagger definition (yaml file) with the IBM API Connect or Strongloop product...but how do I do that, as I don't see any way to export the swagger definition?
I don't have a tutorial, but as I see it you would have to do three tasks minimally:
write your REST APIs (to do what you want to do) - perhaps these
resources on REST APIs will help ? -> Loopback ->
https://developer.ibm.com/code/patterns/create-rest-apis-using-loopback/
and in architectural in general
->https://www.ibm.com/developerworks/library/ws-restful/ and
build the routes for your custom APIs
customise your swagger
definitions to document your REST APIs - this may help you ->
https://www.ibm.com/developerworks/library/wa-use-swagger-to-document-and-define-restful-apis/index.html
and Swagger itself -> http://swagger.io/
If you write custom api and call it as 3rd party api which is mentioned in IBM already it will help you to response but it has very limted scope. I belive you should use swagger to understand its end point are properly configured