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.
#TEAMCITY SERVER HOW TO#
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 kommentar(er)
