search

Azure / open-service-broker-azure

The Open Service Broker API Server for Azure Services
https://osba.sh
MIT License
248 stars 100 forks source link

Problem provisioning a Postgresql for Azure instance in Westeurope #690

Closed ayoub-km closed 5 years ago

ayoub-km commented 5 years ago

Hello world, when I want to deploy a postgresql for azure instance ( with Open Service Broker for Azure using azure-postgresql-9-6 ) to bind it with an existing Azure Kubernetes Service Service Cluster in the region of westeurope, I get an "OrphanMitigation" problem as a status of the instance wether I do it in GUI Service instance of Kubeapps or with the kubectl/svcat commands. but when I change the region to any others ( like east-us or north-europe ) it works and the status of the instance becomes "Ready". Here the results of both instances : the first is north-europe (with ready status) and the second of west-europe that failed after a certain time showing "OrphanMitigation" Status.

     NAME          NAMESPACE          CLASS                PLAN         STATUS
  siam-ha-pgsql        default     azure-postgresql-9-6   general-purpose   Ready
  siam-ha-pgsql-west   default     azure-postgresql-9-6   general-purpose   Failed

is theres any problems in OSBA to deploy in the west-europe region ( because all my deployments needs to be there ) or what ?

Thanks you for your reply and help.

cforce commented 5 years ago

I think that is the same issue i had - see https://github.com/Azure/open-service-broker-azure/issues/681#issuecomment-468948585

You need to define the virtualNetworkRules as below, where (azure.ressourcegroup.vnet) is a placeholder for the "database" subnet of the vnet where your aks is in. The "Virtual Network service endpoint" is a kind of NAT/Fwall abstraction concept so databases are not reachable in the internet, but only in your cluster where you wanna consume it. Maybe you can switch that on/off, anyway using the service endpoints is the right decision from security view anyway. I bet that support for ms sql server has mor comfort and it works without that extra tweak. ;) I also think that OSB could support that feature transparent, because it can query azure api for sub id, resource group id, and vnet subnet with the setup params at OSB hel chart already by itself, so noone needs to do that extra config . Thta should be part of the postgresql class impl. when provisioning against azure.

./svcat provision $(microservice.name).$(namespace.name).db --class $(postgresql.class) --plan $(postgresql.plan) -n$(namespace.name) --params-json '{"cores":1,"storage":10,"backupRetention":7,"tags":{"microservice":"$(microservice.name)","environment":"$(namespace.name)"},"location": "$(azure.location)","resourceGroup": "$(azure.ressourcegroup)","extensions": ["uuid-ossp","postgis"],"virtualNetworkRules": [{"name": "$(azure.ressourcegroup)","subnetId": "/subscriptions/$(azure.subscription.id)/resourceGroups/$(azure.ressourcegroup)/providers/Microsoft.Network/virtualNetworks/$(azure.ressourcegroup.vnet)"}]}'

ayoub-km commented 5 years ago

Thank you, it works when I disable the VNET Service Endpoints, it deployed succefully, and after that I re-enable them without any problem in future connections.

cforce commented 5 years ago

"and after that I re-enable them without any problem in future connections." What di you mean by that. Reenable it shall again block communication between the cluster pod and the posgresql service, if you not have configured on posgresql service to allow thta communication what is doen using the "virtualNetworkRules" param when your provision the posgresql via OSB. Disabling and reanbeling the VNET Service Endpoints can not really be a valid solution to get it working without that extra cfg param, else that would be a major security vulnerability, wouldn't it? Now really confused by your comment.