![]() ![]() I wanted a single resource group that contained all of our data for the cluster, and nothing else.I wanted to keep our storage separate from our AKS cluster, and using a PVC would have created it under the AKS cluster’s automatically created resource group.I’m going to assume we have the following resource groups setup: GroupĪlthough we could have used a Persistent Volume Claim to automatically provision storage for TeamCity, I decided against this for a few reasons: Update our existing build agents to connect to our updated TeamCity server.Edit our TeamCity config for our new server.Copy our existing TeamCity data onto a new Azure Managed disk.Restore the TeamCity database into our new Azure hosted MySQL server.Take a backup of the existing TeamCity database.The rough plan for the migration was as follows: So in this post, I want to talk about the steps involved in migrating our existing TeamCity server from a virtual machine to an AKS cluster. What I didn’t cover in my previous post was what to do if you already have an existing TeamCity server installed on a Virtual Machine, or bare metal. In my previous post I described how to run a TeamCity server in AKS, allowing you to gain all the benefits of containerisation and Kubernetes including efficiency savings, a consistent and easily reproducible way of deploying your infrastructure, and a clear separation of your compute and data. Migrating ResDiary’s TeamCity Server to AKS Blog posts View on GitHub Migrating ResDiary’s TeamCity Server to AKS Migrating ResDiary’s TeamCity Server to AKS | blog-posts Skip to the content. ![]()
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |