-
Notifications
You must be signed in to change notification settings - Fork 58
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
Add Azure Blob storage backend #173
base: master
Are you sure you want to change the base?
Add Azure Blob storage backend #173
Conversation
Allows tfmigrate to use an Azure Blob to store history.
I forgot to update the table of contents again! 🙈 Fixed in 37c7e15. |
Hi @rco-ableton, Thank you for working on this! I appreciate your contribution to the missing feature for Azure users. Before starting the code review, I'd like to discuss the user interface design and acceptance testing. User interface designThe configuration items for s3 and gcs history storage are based on the backend section of tfstate. This is because it is a common use case for many users to store their migration history near tfstate. This does not mean all authentication methods should be implemented from the beginning. We want to start with the minimum number of authentication methods necessary, as implementing them will require testing. However, we would like to align the names of configuration items, environment variables, etc., with those of the tfstate backend unless there is a particular reason not to do so. Based on the above, my proposal is as follows: tfmigrate {
migration_dir = "./tfmigrate"
history {
storage "azurerm" {
access_key = "<storage access key>"
storage_account_name = "storage"
container_name = "tfmigrate-test"
key = "tfmigrate/history.json"
}
}
}
That said, I am an AWS user and have no experience with Azure, so please feel free to point out any mistakes or strangeness from common practice in Azure. Acceptance testingAcceptance testing is essential to ensure that nothing is broken so that multiple cloud providers can be supported and stable. We are currently mocking s3 with localstack and gcs with fake-gcs-server. Please take a look at docker-compose.yml for details. Is there an equivalent for Azure storage? I did some quick research and found Azurite. Do you know how about this one? Or is there any alternative? What do you think of it? |
Hi @minamijoyo! Apologies for the small delay in replying to you. I'm far from an Azure expert, but your proposed interface changes make sense to me, and I've pushed some more commits to address them (we can squash all of these commits down into the original if you prefer). As for acceptance testing, I've never tried using Azurite, but I will take a look and see if I can get it working! |
Hi @rco-ableton, thank you for working on this! I signed up for Azure and tested this branch with the Azure blob storage. Overall, it works well, but I found some issues. (1) The access_key attribute works, but the environment variable ARM_ACCESS_KEY is not. |
Ah, my mistake, I completely overlooked this suggestion in your original comment. Fixed in 92a2f0a.
Sounds good! This should be fixed as of 4d8fc6c. I've also addressed the missing edits to In the meantime I plan to look at getting Azurite working today 🙂 |
The account name and account key are Azurite's defaults (see [1]). [1]: https://github.com/Azure/Azurite?tab=readme-ov-file#usage-with-azure-storage-sdks-or-tools
After some investigation I was able to get Azurite up and running, and have updated I think this should be enough to start adding acceptance tests in the code itself, but I'm not sure exactly what needs to be updated. I see some references to By the way, I will be mostly on vacation throughout May, so please feel free to edit any of my changes as you see fit in the meantime—otherwise I'm happy to pick this up when I'm back! |
Before writing automated acceptance tests, I'm unsure how to test with Azurite manually. In other words, how can we set the request endpoint to Azurite and resolve the hostname in the docker environment? Because the endpoint's hostname includes the storage account name. After reading the document for Azurite, I found that it can change the URL format to a subpath by specifying In addition, the On the other hand, in Terraform's implementation of the Note that tfmigrate doesn't work with the local tfstate backend. The only way I could come up with for testing is to mock tfmigrate's azurerm history storage with azurite, while mocking terraform's s3 tfstate backend with localstack. It's a bit tricky, but it probably works. I have yet to have time to try it out, so please correct me if I'm wrong. |
Allows tfmigrate to use an Azure Blob to store history.
Resolves #21.