Skip to content
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

Several connection strings in one App Service #651

Closed
marchenko-devpro opened this issue Dec 28, 2017 · 3 comments
Closed

Several connection strings in one App Service #651

marchenko-devpro opened this issue Dec 28, 2017 · 3 comments
Assignees
Milestone

Comments

@marchenko-devpro
Copy link

Hi there,

I use Terraform v0.11.1 to create Azure App Service.
Now I have to add 3 different connection strings to the App.
If I use standard approach:

connection_string {
name = "Database"
type = "SQLServer"
value = "Server=mydatabase;Integrated Security=SSPI"
}
connection_string {
name = "Database2"
type = "SQLServer"
value = "Server=mydatabase;Integrated Security=SSPI2"
}

Terrafrom is going to recreate the connection strings each time I run it. As far as I know, this is a well-known issue. We faced the same behavior during creating Security Group Rules in AWS - hashicorp/terraform#11011

So, my question is how we can define several connection_strings in the Application to avoid recreating them.

Thanks.

@achandmsft achandmsft added this to the Soon milestone Apr 20, 2018
@tombuildsstuff tombuildsstuff modified the milestones: Soon, Being Sorted, 1.20.0 Oct 25, 2018
@tombuildsstuff tombuildsstuff modified the milestones: 1.20.0, 1.21.0 Dec 3, 2018
@andydkelly-ig
Copy link

andydkelly-ig commented Dec 4, 2018

I have a similar issue not sure if it's the same. I have 2 Connection Strings in an Azure App Service and each time i run terraform plan it wants to change the order:

~ module.devuat-govern-jobapp.azurerm_app_service.default connection_string.0.name: "AzureWebJobsServiceBus" => "AzureWebJobsDashboard" connection_string.0.type: "ServiceBus" => "Custom" connection_string.0.value: <sensitive> => <sensitive> (attribute changed) connection_string.1.name: "AzureWebJobsDashboard" => "AzureWebJobsServiceBus" connection_string.1.type: "Custom" => "ServiceBus" connection_string.1.value: <sensitive> => <sensitive> (attribute changed)

if i allow this change to happen and run terraform plan again i will get

~ module.devuat-govern-jobapp.azurerm_app_service.default connection_string.0.name: "AzureWebJobsDashboard" => "AzureWebJobsServiceBus" connection_string.0.type: "Custom" => "ServiceBus" connection_string.0.value: <sensitive> => <sensitive> (attribute changed) connection_string.1.name: "AzureWebJobsServiceBus" => "AzureWebJobsDashboard" connection_string.1.type: "ServiceBus" => "Custom" connection_string.1.value: <sensitive> => <sensitive> (attribute changed)

Please advise

@kplantus
Copy link

kplantus commented Dec 26, 2018

I have this issue as well where I have 6+ connection strings in single web apps.
It seems that it randomly chooses the connection string order, and it's always different.

I currently have this as a workaround:

lifecycle = {
    # to ignore connection strings  
    # ignore_changes = ["site_config.0.scm_type", "connection_string.0", "connection_string.1", "connection_string.2", "connection_string.3", "connection_string.4", "connection_string.5"]

    # when we need to update connection strings
    ignore_changes = ["site_config.0.scm_type"]
  }

@ghost
Copy link

ghost commented Mar 5, 2019

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 [email protected]. Thanks!

@ghost ghost locked and limited conversation to collaborators Mar 5, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants