none
Clarification on meaning of "Sticky to Slot" for deployment slots

    Întrebare

  • I'm reading these two articles as carefully as I can and I'm confused on one point.

    https://blogs.msdn.microsoft.com/benjaminperkins/2017/09/04/database-connection-string-when-swapping-between-app-servers-slots/

    http://blog.amitapple.com/post/2014/11/azure-websites-slots/#.W0ftCtVKj4Z

    The question like this:

    WAIT!  If the swap is only changing the DNS, then why do we have to be concerned about connection strings being sticky to a slot or not?

    Is this the answer?

    The deployment slots are real physical entities with internal names like X1 and X2 (actually probably GUIDs, but whatever).

    We call X1 the production slot, and we call X2 the staging slot. 

    But those names only mean which URL point to them:
    production.mydomain.com points to X1 so it's the production slot, and staging.mydomain.com points to X2, so it's the staging slot.

    And the names "Production" and "Staging" are just external logical, user friendly names, for whatever the corresponding URL is pointing to.

    When we swap, then X1 becomes staging (staging.mydomain.com points to it), and X2 becomes production (production.mydomain.com points to it)

    In fact the slots are still just physically X1 and X2. 

    Sticky to the Slot then means: sticky to the "logically named" slot. 

    Then suppose X1 is "Production" and has connection string A.  If we make connection string A sticky to "Production" we are in fact making it sticky to the production URL.

    Then when we swap, and X2 becomes "Production" (i.e. the production URL is pointed to it), then connection string A is then applied to S2 (i.e. connection string A becomes associated with whatever the production URL points to).

     ==> Question 1: Is that correct?

    If so, then what actually happens?  Is the physical connection file physically copied to the "production slot"?  Or is it just pointed to from the production slot?  Seems like it would be risky to just point to it, because if that "other" slot got changed, then the connection string might get lost, and ... no connection.

    ==> Question 2:  Does making a connection string sticky to a URL mean that it gets copied to the slot associated with that URL?

    Next, if the answer to Question 1 is yes, then I assume that if I looked at the Deployment slot controls in detail (when the fog clears in my head), then I would see that WHEN I MAKE THE STICKY ASSIGNMENT, I'm assigning it to a Slot that is clearly identified as Production (or staging, if that's the case), and that there is some clear correlation of the name Production with the production URL.

    ==> Question 3:  Is that correct?

    Any guidance on this would be appreciated.

    Thanks!




    vineri, 13 iulie 2018 01:21

Toate mesajele

  • Hi,

    I think that this will help to better understand the issue:

    Let's assume that we have application named App01 which have DNS DNS01 and this app connects database DB01. In addition we have second app named App02 which have DNS DNS02 and this app connects database DB02.

    App01 serves and production which mean that DB01 includes the real data from the production

    App02 serves for testing which mean at this point DB02 does not have any production data

    Now we do a swapping...

    Swapping means that the DNS swaps from one slot to the other.

    App02 get the production DNS which mean that the DNS01 now point to App02 while DNS02 point to the old App01.

    The problem is with the databases...

    the connection string is usually configured in the application level, and swapping  between the app does not change the connection strings inside the applications, which mean that App02 which is now production still connects to DB02 which is not the production database

    Therefore, we need a way to swap the Apps and keep working on the production database. This is achieved by making the setting ‘sticky to the slot’. meaning App02 which become production will swap the connection string to use the production database DB01 instead of continue working with the test database.

    * By the way, this is best to ask the question in Azure Wep App forum and not here as this is not related to the Azure SQL Database but to the app side.


    signature   Ronen Ariely
     [Personal Site]    [Blog]    [Facebook]    [Linkedin]


    sâmbătă, 14 iulie 2018 06:20
    Moderator