#TEAMCITY KUBERNETES FULL#

The tests verify that our api respons as expected.

Before the deploymentĭuring deloy we add the new version and a new temporary ingress for smoke tests. Red if it failsīefore the deployment we have a service and the apps in V1, and an ingress which we'll reuse. Annotations in application insights, blue is start of deployment and green is posted on success.

The deploymen also contains a link to our internal release note which has a list of all pull requests since the previous version. When we start rolling our a deployment we place an annotation in Applications Insights, making it easy to correlate any anomalies with the deployments. We chose the latter as we also version our Service Bus topics. When deploying Orleans to Kubernetes I would either go for a single StatefulSet or multiple deployments. I've written about our state versioning technique in a separate blog post. Orleans supports blue green deployments, with multiple versions of the same grain type, given the interfaces is versioned as well as versioning state if need.

After deployment Octopus wil create annotations in Application Insights and notify on slack.

Octopus deploy will execute the deployment script against Kubernetes.Octopus will create deployment started annotations in Application Insights.TC will upload a support package to octopus which contains our deploymen script, config file templates ++.TC will upload the 3 images to Azure Container Registry.When something is comitted to master, TC will trigger a build using our docker build container.CI/CD Pipeline with Github, TeamCity, Octopus Deploy, Azure Container Service and Azure Kubernetes Service We currently run in one data center only as the service provides added value, not primary functionality. Finally we have our production environment. The next environment is our pre-production where data is replicated from our production environment at regular intervals. The first environment we deploy to, stage, has data we can modify to provoke failures. The deployment will go through two environemnts before our production environment. The deploy pipeline is rather straing forward, and fully automated from the point a pull request is merged to master. It is not related to the actual hosting model.z Deployment pipeline The clustering provider is just for reading and writing cluster information. We do not use the provider, we use AzureStorageClustering. Users perform both read and write operations using the API, all writes goes through Azure Service Bus before being picked up and persisted (we're considering writing directly by default and only use Service Bus in case of write failuers). From deployment perspective and important detail is the use of Azure Service Bus Deployables Our application consists of 3 deployables, an API running together with Orleans (the direct client is quite a bit faster), a service processing write messages from the API and another service processing messages from our internal systems. In this blog post I will give an introduction to our application, continuous delivery pipeline and how we deploy to Azure Kubernetes Service (AKS) without downtime. How we do our deploys will touch base on multiple subjects, such as state versioning, testing, feature toggles and metrics. A safe and sound deployment regime is the basis for running Orleans in production, so documenting how we do this will be my first contribution. On GitHub there is an issue to gather details for Orleans production usage, and recently k8s popped up in the chat for the latest virtual meetup.

#TEAMCITY KUBERNETES FULL#

We've been running Microsoft Orleans in Kubernetes for nearly 2 years, and for the last half year or so we've had full continuous delivery whenever we commit to master branch in GitHub.

Teamcity kubernetes