-
Notifications
You must be signed in to change notification settings - Fork 205
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support creation of APIM and also configuration of APIM #2747
Comments
Feel free to ping me if you need help from the APIM side @matthchr |
I was looking at crossplane and it appears to support APIM instance creation and API configuration: https://marketplace.upbound.io/providers/upbound/provider-azure/v0.30.0/crds?query=api I'm looking for something similar in ASO. |
Seems to contain the REST API spec for this RP. There are quite a few resources in there but there may be a subset we could focus on for a v1 release. |
We have a requirement to support the following.
Our intention is to deploy microservice(s) to K8s and as part of the deployment, configure the Api, VersionSet and add a PolicyFragment into a ProductPolicy so that we can route traffic to a Backend. A product will be the same as a k8s namespace until workspaces are released. Some of these backends will also use authorisations. NamedValues will be used for any KeyVault Secrets we may need. |
@clarenceb what resources are you specifically interested in? Gateway resource? |
Hi, quick question. I have a Service, API, Subscription, Named Value, Policy and backend. But i'm missing the Operation Part to create the Endpoints. |
That is a gap I noticed yesterday as well. @ross-p-smith are you using API import method or how did you creat operations? |
I did some grep'ing through the APIM code in ASO for the term |
Jup, I've added a note on APIM side to contribute this |
Has anyone managed to create a backend with a named value as header? I have a named value "api_key" that i want to reference in the backend
when i do this a header with the value "api_key" is added (manual value) The Docs only describe the authorization like this: Has anyone managed to reference the named value here? |
@tomkerkhove do you have an example of usage of this field? For example in an ARM template? That could inform our samples/examples in ASO as well. |
Yes this is a gap - I have not implemented the Operations yet |
@clarenceb Based on what is available now, are you OK with closing this item or not? |
@tomkerkhove this is very timely! I didn't see your comment but, by coincidence, happened to stumble upon this feature being progressed since I raised the issue as I have a few customer instances where this could benefit them. I will take a look today and test it out and let you know. At first glance, it does appear to have the main constructs. Thanks for your efforts! |
Based on the discussion here I am closing this. I think we can track these gaps via the apim issue label, specifically these two issues: |
Support creating a new APIM instance and configuring high level aspects like products, subscriptions, workspaces, etc.
Also, support configuring APIs along with their associated policies. Ideally, allow scoping to a workspace so different teams can configure their own APIs. This would be a simpler alternative to the API Management DevOps Toolkit.
New CRDs would be needed to capture things like APIM Policies associated with an API.
I have a customer using Backstage.io to onboard and configure APIs into APIM. They built their own REST API to manage APIM and their own YAML spec for the API definition and linked policies. Having ASOv2 support this would mean they can decommission their own bespoke solution.
Also, with API Management Self-Hosted Gateways in Kubernetes, ASOv2 can simplify the configuration of these gateways and support the "microgateway" pattern. Another benefit would be that GitOps can be used to manage API backend deployments to Kubernetes and also configure the associated APIM gateways for the exposed API - rather than using two separate CI/CD pipelines that are disconnected from each other.
Overall, this allows teams to own their API gateway configuration and Kube deployments - as well as any other Azure PaaS resources needed for the app (databases, storage, monitoring, app insights, etc.) This would simplify their devops processes, give them more ownership with some guardrails - APIM workspace, Kube namespace, Workload Identities, etc.
The text was updated successfully, but these errors were encountered: