Teamcity kubernetes how to#
Teamcity kubernetes update#
Teamcity kubernetes manual#

With a running pod I can now stage some configuration for my TeamCity database. #get pods (confirm mysql container is running) Claims use capacity and access mode to determine which volumes to bind to do fulfill the claim. These define how the pods can read and write data to the volume. There are a few different accessModes ReadWriteOnce, ReadOnlyMany and ReadWriteMany. accessModes define what operations can be performed on the volume.

Claims use this information to determine which persistent volumes it can bind to. It’s the amount of space available for a claim to take. Capacity and accessModes are used by the persistent volume claims. There are two important pieces of information that are worth explaining a bit more. These options will change with the type of storage you choose to use. You’ll have to give it a name, storageClassName, specify the capacity, access modes and path since I’m using the local storage type. The manifest requires a few details about the storage that will be provisioned. You’ll have to define a Kubernetes manifest with the kind of PersistentVolume. For now, let’s keep it simple and provision it by hand. Persistent volumes are provisioned by cluster administrators or dynamically provisioned using storage classes. You can think of a persistent volume as a datastore to steal some vmWare terminology. Persistent Volume & Persistent Volume Claim.In this blog post I’ll be using a persistent volume and persistent volume claim. By doing so you decouple the data layer and the application layer. The other option you have is to create a persistent volume and persistent volume claim. It also requires that you have a good understanding of the data layer. This will make scaling and management of the data layer more difficult. By defining the volume in the Pod spec you couple the data layer in with your application. While this is the simplest option, but it also had a draw back. Which means that you define the volume and mount it within a single Kubernetes pod spec. You can create the volume as a pod volume. There are two options you have used when creating persistent volumes.

Teamcity kubernetes manual#

Manual Clean Up With Local Persistent Volumes.Understanding Persistent Volume Reclaim Policies.Using Persistent Volume Claims with Deployments.Methods for Creating Persistent Volumes.The example I’ll be using in this blog post is persisting data stored by mysql for hosting a TeamCity database. With that in mind how do we keep the data the container wrote? Persistent volumes answer that question.

Teamcity kubernetes update#

Everytime you want to update the container, you delete it and replace it with a new one.

When administering containers on the other hand the deletion of a container happens all the time. Which we all know is a very unlikely scenario. You only delete it when it is time to decommission it.

You create a virtual machine and make changes to that virtual machine. The reasons for that is most virtualized environments are static. If you’ve been working with virtual machines most of your career this isn’t something you’ve given much thought. Before we dive in first let’s answer the question of why would you create a persistent volume? Because of that the maintenance of the volumes is a bit different than you’d expect. Because of this, there isn’t an easy way (at least that I’ve found) to access the node running in the docker-desktop instance that hosts the Kubernetes cluster. I’ll be using a Kubernetes cluster running within docker-desktop. A local volume represents a mounted local storage device such as a disk, partition or directory. There are several volume types in Kubernetes, but to get started I’ll be using the local volume type.

Teamcity kubernetes how to#

In this blog post, I’ll be walking through how to create a persistent volume in Kubernetes.