SAP-samples / btp-cap-multitenant-saas

Sample project that demonstrates how to setup a multitenant application for a Software-as-a-Service scenario, leveraging the Kyma and Cloud Foundry Runtimes of the SAP Business Technology Platform. Developers learn how to implement their own CAP (mtxs) based SaaS app including an SaaS API and integration with various essential SAP BTP service of...
Apache License 2.0
75 stars 38 forks source link

Question: Blue-green deployment strategy #18

Closed geert-janklaps closed 6 months ago

geert-janklaps commented 6 months ago

Hi,

I'm using this example as a basis for a multitenant solution built on top of cloud foundry. This setup seems to be working perfectly fine when using a default deployment configuration.

Once we start using a blue-green deployment strategy the subscription breaks, because the url of the onSubscription & getDependencies of the SaaS Provision Service is set to the temporary route of the blue-green deployment strategy, but not updated once the new version is up and running.

Any ideas on how to handle this?

Cheers, Geert-Jan

alperdedeoglu commented 6 months ago

Hi @geert-janklaps,

Thank you very much for spending time to investigating the root cause. Can you please check if skipping idle start is suitable for your scenario? If yes can you try the command below for the the deployment?

cf deploy mta_archives/* --strategy blue-green --skip-idle-start

PS: Skipping idle start assumes that you have already running a deployment as mentioned in documentation I shared.

geert-janklaps commented 6 months ago

Hi @alperdedeoglu,

skip idle start would certainly be an option for us to use, since we don't want any manual interaction anyway and initially we'll deploy using the default strategy. I've tried the command as you proposed, but unfortunately it seems to cause the same problem.

I guess this is because the processing of the services is done at the beginning of the MTA deployment (probably with the temporary route) and no update of the services is triggered after successfully binding the default routes to new applications.

In parallel I've logged ticket 161897/2024 as well, so it can be investigated further.

Cheers, Geert-Jan

alperdedeoglu commented 6 months ago

Thank you very much for addressing the issue, and thanks for keeping here updated. I appreciate that. In the meantime I also have done some research, I would recommend the solution below. (Please check the value change on the provides section of susaas-srv module )

# --------------------- SERVER MODULE ------------------------
  - name: susaas-srv
  # ------------------------------------------------------------
    type: nodejs
    path: ../../code/gen/srv
    build-parameters:
      builder: npm
      ignore: [ '.DS_Store', 'node_modules/', 'default-*.json', 'manifest*.yml']
    parameters:
      app-name: susaas-srv-${space}
      memory: 256MB
      disk-quota: 1024MB
      command: node ./node_modules/@sap/cds/bin/cds-serve
    properties:
      tenantSeparator: ~{susaas-router-api/tenant-separator}
      appDomain: ~{susaas-router-api/app-domain}
      brokerName: ~{susaas-api-sb-srv/app-name}
      srvUrl: 'https://${app-name}.${default-domain}'
      brokerUrl: ~{susaas-api-sb-srv/srv-url}
      approuterUrl: ~{susaas-router-api/app-url}
      appName: ~{susaas-router-api/application}
    requires:
      - name: susaas-uaa
      - name: susaas-credstore
        parameters:
          config:
            authorization:
              default_permissions:
                - read
                - decrypt
                - encrypt
                - list
      - name: susaas-logging
      - name: susaas-registry
      - name: susaas-service-manager
      - name: susaas-service-manager-admin
      - name: susaas-destination
      - name: susaas-html5-repo-runtime
      - name: susaas-alert-notification
      - name: susaas-api-sb-srv
      - name: susaas-router-api
      - name: susaas-autoscaler
        parameters:
          config:
            instance_min_count: 1
            instance_max_count: 2
            scaling_rules:
            - {"metric_type": "memoryutil","threshold": 80,"operator": ">=","adjustment": "+1"}
            - {"metric_type": "memoryutil","threshold": 60,"operator": "<","adjustment": "-1"}
            - {"metric_type": "cpu","threshold": 80,"operator": ">=","adjustment": "+1"}
            - {"metric_type": "cpu","threshold": 30,"operator": "<","adjustment": "-1"}
      - name: susaas-com-hdi-container
        group: SERVICE_REPLACEMENTS
        properties:
           key: com-hdi-container
           service: '~{com-container-name}'
      - name: susaas-ias-app
        parameters:
          config: 
             credential-type: X509_GENERATED
    provides:
      - name: susaas-srv-api
        properties:
          srv-url: https://${org}-${space}-${default-app-name}.${default-domain}

With this approach the url should be constructed in a way that it is not effected from idle deployments, therefore subscription should work seamlessly.

Then you can deploy with the command below:

cf deploy mta_archives/* --strategy blue-green --skip-idle-start

geert-janklaps commented 6 months ago

Hi @alperdedeoglu,

Thank you for the guidance on this one! Your suggestion did solve the issue, blue green deployments are working as expected!

Cheers, Geert-Jan