Manage Azure DocumentDB using PowerShell
We need a PowerShell module for managing Azure DocumentDB
Cosmos DB now provides support for PowerShell for all resources including account, database, container and throughput.
For more information see the article below for samples.
Thank you for your suggestion and votes.
Lester W commented
Sadly, the PowerShell examples only show how to create databases and containers and do not show how to insert items into a container
Swanger, Susan commented
You can't automate CLI scripts with a Runbook. And you can't adjust Throughput with PowerShell. Provide Powershell cmdlet for Throughput or Provide a way to schedule CLI scripts.
Scalling up/down can already be done via powershell.
check out https://github.com/PlagueHO/CosmosDB#working-with-offers
Kirk Munro commented
Please support scaling up and down in the PowerShell cmdlets as well.
Although it is not a solution in ARM it can 'easily' be done via powershell. here are the links to the module and it's project:
Actually, I think this is already solved here: https://www.powershellgallery.com/packages/CosmosDB/
Nathan Smith commented
I'm sorry but this is a complete cop out. What about people who don't use Azure "DevOps"? I truly don't understand the reluctance or inability to do this.
Michael Jonsson commented
In an enterprise IT enviroment the IT department is commonly split with responsibilities, in those scenarios the DB often falls under the Infra team and today the infra is provisioned with code (ARM).
So for a foreseeable future the "silos" in large enterprise IT will exist and not beeing able to provide a Cosmos DB infrastructure via Code is a gap currently.
I Second that this would be nice to have and ask to please reconsider.
Joseph Workman commented
Would really like the team to reconsider this solution. Currently I am developing an ARM template that deploys CosmosDB, an Event Hub, and then a stream job that outputs event data to a cosmos collection. Because this cannot be defined in the template, we need to have a separate build step to create the collection(which also leads to this error in Azure CLI: https://github.com/Azure/azure-cli/issues/6272)
This results in having to have multiple arm template deploy steps, with azure cli steps inbetween, and the Pipeline gets bloated/very interdependent.
This also makes deploying the same template from the portal error prone because the user needs to do the manual db/collection creation steps in between running the different templats
Please reconsider this as we want to be able to automize the setup of our environments so that we can eliminate the human error. As i've been told ARM is the way to go in Azure. if we need to have the creation of our infrastructure in different places it gets far less manageble.
Looking to most responses, I get the impression that it is a duplicate of feedback item 'Create DB, Collections using ARM template'.
Perhaps it is an idea to focus this item to more to which functionality should be supported via powershell explicitly?
Remarks (and VOTES!) regarding creating/changing DocumentDb resources (other than account) are of course welcome at the duplicate item mentioned above.
Scott Shurts commented
If there is support for dacpacs to manage a sql database in a CI/CD pipeline (with minimal effort) then I'm not understanding why the Azure team doesn't recognize the gap in managing a Cosmos DB as easily. Suggesting that there are APIs or SDKs to achieve the goal is missing the point.
We have a VSTS pipeline set up to deploy our Cosmos DB Account, and it would be very helpful to specify collection settings (ttl, shard key, throughput, and collection name) in an idempotent way via an ARM template.
Since this is not available, we have to dynamically whitelist our build agent's IP address in our Cosmos firewall via template deployment, sleep 5 minutes for the firewall configuration to actually take effect, use the Azure CLI to interrogate the current state of our collections, and then remove the build agent's IP Address from the firewall.
This process is cumbersome and causes very slow builds. We could avoid the whole IP whitelisting dance if collections/databases could be specified via ARM template.
Max B commented
I find it interesting how Microsoft maps Resource Manager (and some GUI tools) to CloudFormation here https://www.microsoft.com/en-us/download/details.aspx?id=56124&WT.mc_id=rss_allproducts_cloudservice when this and other examples are clear evidence that Resource Manager is not comparable to CloudFormation at this time. I wonder how many other Azure services that are claiming to be "common" to both providers suffer from the same incompleteness as ARM? Infrastructure as code is vital for serverless operations to be as efficient as possible.
Is it recommended for CI/CD tasks we just create our own tools made up of ARM templates, script files, and possibly a few azure cli commands to achieve the automation, repeatability, and maintainability CI/CD provides?
Rasmus W. commented
I really hope that you reconsider dismissing this request. Being able to deploy the complete set of resources for a service through ARM is essential for CI/CD. It is possible to create not only SQL servers, but also databases with ARM. Why have it differently for Cosmos DB?
Étienne Brouillard commented
This should be a definite must have and not a last mile request. It's not possible to configure a complete autonomous ci/cd without this and impedes our capacity to deploy our CosmosDB efficiently.
Checking if a database and collection exist every time I instantiate my connection to Cosmos DB, and create it if does not exist (only once to be exact) is an expensive operation, especially in a serverless architecture.
I can understand that it might be a problem when the throughput has been changed manually because of the idempotent nature of ARM templates, but that can be resolved similar to appSettings: overwrite when deployed. And update the setting not only in the portal, but also in the CD pipeline..
Oliver Tomlinson commented
If we really aren't supposed to manage these "runtime resources" as has been explained to us, then what are we supposed to do?
It feels like Azure have failed to educate us on *why* it has to be this way. Its alright saying 'collections and indexes are realtime resources' but what does that *mean* to me as an engineer, because it isn't apparent.
Please either support what we are asking for, or educate us why it **must** be this way. Thank you
VidhyaSagar Karthikeyan commented
I agree we can do this via SDK and Rest API however from a provisioning \ automation perspective we have to two code base one with ARM to create till the DB and other code is using powershell to create collections, set RU and so on. It will be great if this can be included in ARM template so that we can have everything in a provisioning project.
Vincent-Philippe Lauzon commented
Currently the only automation through ARM Template is the Account creation. CLI supports DB + Collection creation. PowerShell create account, update firewall & keys.
It would be useful to have ARM Template & PowerShell support for DB objects such as collection, users, sprocs, functions & triggers. This would allow automation of a ready-to-go Cosmos DB account.