Challenges of implemeting the OSB API (KubeCon US 2017)
0 likes133 views
The document discusses some of the challenges in implementing the Open Service Broker API (OSB), including: - Keeping CREATE and UPDATE request parameters the same to avoid differing schemas - Avoiding reliance on specific platform details and letting the platform handle orphan mitigation - Not assuming specific formats for external IDs provided in requests - The myth of stateless OSB brokers and the need to support operations like rollback and orphan mitigation
Challenges of implemeting the OSB API (KubeCon US 2017)
- 1. Challenges of Implementing the OSB API NAIL ISLAMOV | ATLASSIAN | @NILEBOX
- 2. Service brokers advertise a catalog of service offerings and service plans, as well as interpreting calls for provision (create), bind, unbind, and deprovision (delete). SERVICE BROKERS
- 4. Catalog List of “service classes” (resource types) and their plans (tiers). SERVICE BROKER FEATURES Service Instances Provisioning reserved resource instance Service Instance Binding Creating and fetching credentials for resource instance
- 6. Most of the OSB API decisions have been made at the times of Cloud Foundry Service Broker. OSB
- 7. CloudFoundry Spring Boot MySQL broker example https://github.com/cloudfoundry-community/cf-mysql-java-broker EXAMPLES AWS brokers (built using Ansible broker) https://github.com/awslabs/aws-servicebroker-documentation/wiki Ansible broker https://github.com/openshift/ansible-service-broker/blob/master/docs/introduction.md Other vendors (Azure, GCP) supply their official brokers as well OSB documentation Links to some implementation examples https://github.com/openservicebrokerapi/servicebroker/blob/master/gettingStarted.md Brokers for different languages/platforms Go, Java, NodeJS
- 8. Help the OSB community by opensourcing generic libraries for building brokers in different languages. EXAMPLES
- 9. The only authentication mode explicitly defined in the OSB specification is Basic Auth. AUTHENTICATION
- 10. Bearer Token Auth (JWT, OAuth 2.0, vendor specific implementations) Service Catalog has support for arbitrary Bearer tokens provided via Secret resource AUTHENTICATION Other authentication modes OSB allows a platform to support any other authentication protocols, so feel free to reach Service Catalog or Cloud Foundry folks to add support for yours Basic Auth The only authentication mode explicitly defined in the OSB spec Mutual TLS
- 11. OSB doesn’t explicitly define the requirements of the instance state after the failed update. INSTANCE UPDATES
- 12. Update with the fix Sometimes it might be fine to leave the instance in the “broken” state until the correct update or retries fixes it INSTANCE UPDATES Rollback If possible, rollback to the previous stable state of the instance
- 13. You can define different JSON schemas for instance CREATE and UPDATE requests. But you should think twice before doing that. INSTANCE UPDATES
- 14. Cloud Foundry For some historical reasons Cloud Foundry does not keep the parameters for instance, so every CREATE or INSTANCE request just gets forwarded to the broker. INSTANCE UPDATES Service Catalog Kubernetes API is declarative and asynchronous, so there is little difference between CREATE and UPDATE requests, and it is a challenge to support “diff” for PATCH requests. Update parameters Some parameters might be sensible only for the initial provisioning of the resource, and are immutable
- 15. Keep CREATE and UPDATE request parameters the same. Implement all specifics on the broker side (ignore irrelevant parameters, apply only parameters that have changed since the last provisioning/update). INSTANCE UPDATES
- 16. There is a section in the request that provides platform-specific information. PLATFORM CONTEXT
- 17. PLATFORM CONTEXT { "context": { "platform": "kubernetes", "namespace": “myapp" }, "service_id": "service-id-here", "plan_id": "plan-id-here", "bind_resource": { "app_guid": "app-guid-here" }, "parameters": { "parameter1-name-here": 1, "parameter2-name-here": "parameter2-value-here" } }
- 18. PLATFORM CONTEXT Vendor specific context - RedHat OpenShift - IBM Bluemix - Microsoft Azure Platform specific context - Kubernetes (Service Catalog) - Cloud Foundry
- 19. Avoid relying on a particular platform implementation details if you can. PLATFORM CONTEXT
- 20. OSB makes the Platform (Service Catalog, Cloud Foundry) responsible for the orphan mitigation. ORPHAN MITIGATION
- 21. Implement cleanup in the broker as part of asynchronous provisioning request processing. ORPHAN MITIGATION
- 22. IDs are client-provided in OSB instance/binding requests. Don’t make assumptions about their specific format or pattern. EXTERNAL ID
- 23. Stateless OSB brokers is a myth. Try to be smarter. - Orphan mitigation - Rollback after the failed update - Idempotency - Get ready to support GET requests STATELESS OSB BROKERS
- 24. Services support operations (restart, pause, stop) and jobs (backup, restore). It’s important to automate the Ops side of DevOps. This part is not covered by OSB spec yet. OPERATIONS / JOBS / ACTIONS
- 25. In some situations the service backed by OSB broker might change its state by itself. Currently there is no way to tell the platform to re-sync. SYNC AFTER BROKER DRIVEN CHANGES
- 26. Stateless OSB brokers is a myth. STATELESS OSB BROKERS