Although Kubernetes was originally designed to run stateless workloads, the technology has matured over time and enterprises are increasingly adopting the platform to run their stateful applications. In a survey conducted by the Data on Kubernetes community, 90% of the respondents believe that Kubernetes is ready for stateful workloads, and 70% of them are already running them in production with databases taking the top spot. Having the ability to standardize different workloads on Kubernetes and ensure consistency are seen as the key factors that drive value for businesses.
Nutanix provides an industry-leading HCI platform that is ideal for running cloud-native workloads running on Kubernetes at scale. The Nutanix architecture offers better resilience for both Kubernetes platform components and application data. With the addition of each HCI node, apart from scaling the Kubernetes compute nodes, there is an additional storage controller as well which results in improved storage performance for your stateful applications.
The Nutanix Unified Storage is made available to cloud-native applications with the Nutanix CSI driver. Applications use standard Kubernetes objects such as PersistentVolumeClaims, PersistentVolumes, and StorageClasses to access its capabilities. The CSI driver also enables users to take Persistent Volume snapshots using API objects VolumeSnaphot, VolumeSnapshotContent, and VolumeSnapshotClass. Snapshots represent a point-in-time copy of a volume and can be used to provision a new volume or to restore existing volumes to the previous snapshotted data. OpenShift Container Platform deploys the snapshot controller and the related API objects as part of the Nutanix CSI Operator as described in Blog 3.
Host: Andy Whiteside
Co-host: Harvey Green
Co-host: Jirah Cox
Although Kubernetes was originally designed to run stateless workloads, the technology has matured over time and enterprises are increasingly adopting the platform to run their stateful applications. In a survey conducted by the Data on Kubernetes community, 90% of the respondents believe that Kubernetes is ready for stateful workloads, and 70% of them are already running them in production with databases taking the top spot. Having the ability to standardize different workloads on Kubernetes and ensure consistency are seen as the key factors that drive value for businesses.
Nutanix provides an industry-leading HCI platform that is ideal for running cloud-native workloads running on Kubernetes at scale. The Nutanix architecture offers better resilience for both Kubernetes platform components and application data. With the addition of each HCI node, apart from scaling the Kubernetes compute nodes, there is an additional storage controller as well which results in improved storage performance for your stateful applications.
The Nutanix Unified Storage is made available to cloud-native applications with the Nutanix CSI driver. Applications use standard Kubernetes objects such as PersistentVolumeClaims, PersistentVolumes, and StorageClasses to access its capabilities. The CSI driver also enables users to take Persistent Volume snapshots using API objects VolumeSnaphot, VolumeSnapshotContent, and VolumeSnapshotClass. Snapshots represent a point-in-time copy of a volume and can be used to provision a new volume or to restore existing volumes to the previous snapshotted data. OpenShift Container Platform deploys the snapshot controller and the related API objects as part of the Nutanix CSI Operator as described in Blog 3.
Host: Andy Whiteside
Co-host: Harvey Green
Co-host: Jirah Cox
WEBVTT
1
00:00:02.610 --> 00:00:10.110
Andy Whiteside: Everyone and welcome to episode 52 of mechanics weekly i'm your host Andy white's i've got Harvey green and jarrod Cox hey guys how's it going.
2
00:00:10.380 --> 00:00:12.120
Harvey Green: howdy pretty well.
3
00:00:13.139 --> 00:00:25.320
Andy Whiteside: Is it me or is it a little slower these days in terms of content, coming out it's, not just for new tactics, but for a lot of our vendors is, are we in that time of the year, where we're getting ready to go into summer and people are starting to.
4
00:00:26.910 --> 00:00:28.680
Andy Whiteside: plan their vacations that what's going on.
5
00:00:29.790 --> 00:00:38.550
Harvey Green: i'd say it's either that or they're kinda like me right now, and so busy that you gotta just be here that.
6
00:00:40.650 --> 00:00:46.110
Jirah Cox: Can we both can be very, very busy figuring out where summer vacation is the summer.
7
00:00:47.940 --> 00:00:49.170
Harvey Green: also true.
8
00:00:49.920 --> 00:01:03.420
Andy Whiteside: What could be they were really busy trying to work around working heads down solving real problems, it could be that vacation stuffed chicken in it, it could be that we've solved all the world's problems, and now we just need to coast, the rest of the way.
9
00:01:06.810 --> 00:01:07.050
Jirah Cox: Good.
10
00:01:09.210 --> 00:01:09.720
Jirah Cox: What are you saying.
11
00:01:10.680 --> 00:01:11.460
Andy Whiteside: I don't know and.
12
00:01:13.680 --> 00:01:15.120
Andy Whiteside: Are you guys looking to retire.
13
00:01:16.170 --> 00:01:22.890
Jirah Cox: Somehow I thought solving all the world's problems will feel different, I guess, but there I go having extra expectations again.
14
00:01:23.790 --> 00:01:38.730
Andy Whiteside: Well let's start by solving this one, this one came off the new tannic Community blog for them and it's running staple staple applications with red hat open shift on new tannic hai alright Harvey define what the word state for means in a technology world.
15
00:01:39.780 --> 00:01:54.870
Harvey Green: So staple in harvey's view would mean that the state of that machine will move from one place to the other across reboots so sort of like persistent that easy world.
16
00:01:56.160 --> 00:02:00.810
Andy Whiteside: Right Jerry what state for me example i'm you stay full packet inspections first time I ever heard that word what does that mean.
17
00:02:01.860 --> 00:02:16.950
Jirah Cox: uh yeah I would agree, I would agree with hurry right like means like what the APP does gets written somewhere like persistent is a great word there right like when you stop it and started again, you know what I did is preserved it doesn't just wake up empty, you know no record of transactions.
18
00:02:17.820 --> 00:02:18.960
Andy Whiteside: And that's important.
19
00:02:20.040 --> 00:02:21.060
Jirah Cox: To be I mean.
20
00:02:22.680 --> 00:02:24.990
Jirah Cox: depends, if I guess if you're working my bank could be very important.
21
00:02:26.490 --> 00:02:28.680
Andy Whiteside: Well, unless you're spinning, and you want to go back to what you had today.
22
00:02:28.680 --> 00:02:29.040
Before.
23
00:02:30.120 --> 00:02:41.460
Harvey Green: I mean no, no, I think Jerry be very useful if my bank account started with a million dollars in it every day and no matter what I did the next day and just be out of me, and obviously yeah that would work.
24
00:02:42.750 --> 00:02:45.330
Jirah Cox: i'd, be it would definitely not be very state preserving what it.
25
00:02:47.940 --> 00:02:55.620
Andy Whiteside: What it's kind of a good point I mean, in some cases staples good and you want it that way, in some cases staples bad and you don't want it that way, and you don't want it.
26
00:02:56.880 --> 00:02:58.290
Harvey Green: Well, for example, where you want.
27
00:02:58.530 --> 00:03:00.300
Harvey Green: To start with zero every day.
28
00:03:00.780 --> 00:03:01.230
No.
29
00:03:03.990 --> 00:03:06.630
Jirah Cox: You know, you can spend only what you're allowed to overdraw.
30
00:03:10.050 --> 00:03:14.460
Jirah Cox: yeah that that pin to a certain number of value and it actually matters what that number is.
31
00:03:15.660 --> 00:03:18.510
Andy Whiteside: i'd be at the Bank at 901 now drawing out everything I could.
32
00:03:19.530 --> 00:03:20.550
Andy Whiteside: back there the next morning.
33
00:03:21.660 --> 00:03:23.460
Andy Whiteside: i'd be the bill Murray of Bank of America.
34
00:03:25.080 --> 00:03:26.010
Andy Whiteside: ground on today.
35
00:03:27.720 --> 00:03:29.760
Harvey Green: Yes, I, yes I got it.
36
00:03:31.140 --> 00:03:39.660
Andy Whiteside: Alright, so what's an example of when you would want, I will first of all let me give an example when you wouldn't want state full and that would be like non persistent vdi right, whatever that.
37
00:03:40.350 --> 00:03:46.650
Andy Whiteside: Whatever that junk is you put in your virtual desktop that you don't want to be there for various reasons, I can tell you, while ago I fell for the.
38
00:03:47.310 --> 00:03:55.980
Andy Whiteside: there's a puppy dog last outside email and I clicked on it, for whatever reason, and I got this big of the website, I hope, came from my own team saying we got you you shouldn't have been doing.
39
00:03:55.980 --> 00:03:56.310
Jirah Cox: That.
40
00:03:56.850 --> 00:03:59.490
Andy Whiteside: Can you I don't know I closed it so fast I don't know exactly what it said.
41
00:04:02.370 --> 00:04:03.930
Andy Whiteside: Something like i've been owned or something.
42
00:04:04.560 --> 00:04:06.660
Harvey Green: yeah yeah sounds about right.
43
00:04:07.230 --> 00:04:18.030
Andy Whiteside: But in this case staple in the world of your tactics and specifically in the world of Linux and more smoothly in the world of red hat open shift what's what's that mean the direct.
44
00:04:18.600 --> 00:04:23.280
Andy Whiteside: answer that question, then, also include what what is red hat open shift has been a while, since we talked about.
45
00:04:23.700 --> 00:04:33.510
Jirah Cox: yeah so so in order right like an APP that could need stapling those could be like in this case and we'll talk about this example, like a database right, I want to run a database, you know.
46
00:04:35.520 --> 00:04:43.290
Jirah Cox: For any use case, other than managing andy's bank account, then i'd want it to like record transactions and like you know, save the data that I write to it.
47
00:04:44.250 --> 00:04:54.180
Jirah Cox: Probably applies to just about any application we run in the data Center right if we give it storage and people will agree with that storage was not there that application has some state to it.
48
00:04:55.770 --> 00:05:01.980
Jirah Cox: And that you know, only a small handful of things wouldn't fall in that right like, if I had a load balancer maybe that.
49
00:05:03.420 --> 00:05:11.490
Jirah Cox: You know I can send an API call to say hey add a new back end leg the load balancer and then it goes away and it's very transient.
50
00:05:12.270 --> 00:05:22.440
Jirah Cox: That APP has not a lot of State to it right when it boots up again if it came up with nothing I reinject all those same kind of routes and bring it back to life, but for the most part, just about everything we have state to it.
51
00:05:23.640 --> 00:05:27.570
Jirah Cox: Open shift right is red hat's platform for running containerized applications.
52
00:05:29.100 --> 00:05:39.960
Jirah Cox: On their frameworks, of course, on the tanks hdi as well, so very valued partner of ours, and a great way to run open shift, so if you're looking for an easy way to launch a containerized infrastructure.
53
00:05:40.890 --> 00:05:48.270
Jirah Cox: very easily right very consistently in and actually have you know, I think it kind of is like a opinionated way to run containers that.
54
00:05:49.410 --> 00:05:54.180
Jirah Cox: kind of like if you're thinking about a factory, you could of course install any number of container frameworks.
55
00:05:55.080 --> 00:06:02.070
Jirah Cox: and give yourself an empty factory bear floors you get to do everything from the ground up, whereas I think it open shift is more like.
56
00:06:02.460 --> 00:06:06.300
Jirah Cox: A very opinionated like this is where the conveyor belt already is tooling already here.
57
00:06:06.750 --> 00:06:17.190
Jirah Cox: Bringing your own materials and just start cranking out the widgets that you want to make right so there's a lot, a lot more things that are available to you and already pre plumbed on day one, when you open up open up business.
58
00:06:20.190 --> 00:06:21.330
Andy Whiteside: Harvey i'm.
59
00:06:22.800 --> 00:06:29.310
Andy Whiteside: Where does, where does that fit in the world of Cooper nettie isn't needing to run that stable workloads.
60
00:06:30.240 --> 00:06:44.400
Harvey Green: Well, I mean the biggest piece is the one that we kind of already hit on a few times around whether or not you need data to remain each day or each time that application and started again.
61
00:06:45.630 --> 00:07:02.280
Harvey Green: You know if if you don't if you know if every day or every time that application is run it's working a job to completion, and you just wanted to do a new job to work to completion, again, then you don't necessarily need something stable, but if you have you know something that.
62
00:07:03.510 --> 00:07:16.200
Harvey Green: needs to keep a certain set of information every day or start with where it left off the last time it was running you definitely would want something stable that's keeping up to that are keeping up with that I should say.
63
00:07:19.740 --> 00:07:27.960
Jirah Cox: Well, and so I mean essentially cabernets there Andy and this article opens with a great discussion about you know pulling the Cubans Community right and.
64
00:07:28.290 --> 00:07:33.210
Jirah Cox: respond respond and saying you know 90% of them say absolutely ready for running staple workloads.
65
00:07:33.660 --> 00:07:50.700
Jirah Cox: And that a good chunk of them 70% are already running it in production right so then it comes down to you know let's walk through kind of a an over your lunch break lab exercise around how to actually get that up and running, you know, in a in a demonstrated will fashion.
66
00:07:52.830 --> 00:08:02.280
Andy Whiteside: So is this asking what percentage of Cooper daddy's users are able to do stay faithful versus the ones that can't.
67
00:08:03.600 --> 00:08:13.650
Jirah Cox: um this survey which actually links to where it talks about Community perception is Cuban Community perception of is Cooper 90s ready to run production workloads.
68
00:08:14.130 --> 00:08:22.710
Jirah Cox: With state full applications right and that's the overwhelming 90% there yet, is a yes and then most of those people saying yes already are doing it as well.
69
00:08:28.920 --> 00:08:30.030
Andy Whiteside: So I guess i'm.
70
00:08:32.040 --> 00:08:33.870
Andy Whiteside: I guess I don't live in that world I really don't.
71
00:08:35.340 --> 00:08:48.990
Andy Whiteside: know where your containerized workloads have had stayed fullness and where they haven't I guess it was there a big percentage of time where wasn't available as a persistent workload I stayed for workload.
72
00:08:49.440 --> 00:08:57.450
Jirah Cox: So by native by default when you when you launch a container running an application right the container itself is not changing.
73
00:08:58.830 --> 00:09:04.710
Jirah Cox: i'm not sure if it's 100% immutable intrinsically but it doesn't change it's not you're not saving data into the container.
74
00:09:05.190 --> 00:09:15.420
Jirah Cox: You have to give it extra storage right where it can you know, keep those to itself right configurations even right, you know actual contents like a database container would write the actual database.
75
00:09:16.500 --> 00:09:29.610
Jirah Cox: tables and payloads and so forth yeah so so until you're providing that that container storage and storage for your containers your containers probably aren't saving much now they can connect to other databases that backend systems.
76
00:09:31.110 --> 00:09:39.360
Jirah Cox: hold on configuration data to provision themselves but but yeah the by itself it's not there's not a provision fruit for that cost storage.
77
00:09:39.600 --> 00:09:48.990
Andy Whiteside: And that's kind of by design rats how Cuban 80s was built the idea of the container where would have its database and it was the application workload in it, it would get what it needed for like a config.
78
00:09:49.410 --> 00:09:50.580
Andy Whiteside: And, but anyway run.
79
00:09:50.730 --> 00:09:58.410
Andy Whiteside: But then it would write as data, the database and then it would just go away or reset back to its original state when you when it was turned off that.
80
00:09:58.590 --> 00:10:08.130
Jirah Cox: Totally yeah so like in the in the parlance or in like the framework of you know let's say enterprise it 20 years ago right, where I had to build a server to run an application.
81
00:10:08.670 --> 00:10:15.330
Jirah Cox: The application came with installer right next next finish and I brought the storage in the form of whatever I gave that server fiscal are virtualized.
82
00:10:16.770 --> 00:10:26.400
Jirah Cox: And then you know, of course, the APP packaging right that, like that MSI file had to unpack the the application workload and then tailor it for that environment was in a run in.
83
00:10:26.820 --> 00:10:35.220
Jirah Cox: And containerization says let's get rid of all of that right, I don't need to unpack it I don't need to tailor it I can literally just take it from a file download from the Web to it is running.
84
00:10:36.420 --> 00:10:44.550
Jirah Cox: pretty much instantly right within configurable networking and configurable storage, but the the application itself doesn't have to get modified to to then be able to instantiate.
85
00:10:45.000 --> 00:10:54.600
Andy Whiteside: i'm kind of seeing this like you know I move into a apartment or economy warehouse and I got to unpack get all my stuff there, and my stoves there, and all that goes along with the baggage of my stuff being there is there.
86
00:10:55.350 --> 00:11:05.460
Andy Whiteside: versus the Cooper nettie is where it's coming in and and I leave the next day and so by cleans it back to the original state in this case, I can leave a little I believe a little me behind So when I come back i'm not starting to.
87
00:11:06.060 --> 00:11:10.890
Jirah Cox: yeah in some ways right, I mean you're Groundhog day analogy from before was a bit apt yeah.
88
00:11:12.450 --> 00:11:12.930
Andy Whiteside: um.
89
00:11:14.340 --> 00:11:18.450
Andy Whiteside: And what's an example of things I would leave behind configuration type of information.
90
00:11:20.220 --> 00:11:26.610
Jirah Cox: yeah for sure right like I run I run a containerized a load balancer here at my house that that you know it writes know to itself about.
91
00:11:27.000 --> 00:11:33.510
Jirah Cox: You know what back end sites, do I want to proxy or load balance and what how to access them and what ports and.
92
00:11:34.380 --> 00:11:50.430
Jirah Cox: Health monitors right, so the actual code that runs the load balancer doesn't change when I start or stop the container but, when it does start up you know it, it or after an hour container update it finds that configuration file on storage, I presented to it, and it will reconfigure itself.
93
00:11:51.510 --> 00:11:55.710
Andy Whiteside: And what's the magical piece of new tannic hyper converged that makes that happen.
94
00:11:56.520 --> 00:12:03.510
Jirah Cox: So in this case like no what this article illustrates right is actually that the CSI driver right the container storage.
95
00:12:05.040 --> 00:12:15.720
Jirah Cox: driver that lets the container eyes framework in this case like open shift know how to how do I request storage resources from the new tonics cluster that i'm running on right in this case we it'll use like a.
96
00:12:17.370 --> 00:12:19.440
Jirah Cox: New thanks volumes like a block storage.
97
00:12:21.720 --> 00:12:34.620
Jirah Cox: presentation, it can also be you know, a files over SMB or nfl but for this example it's gonna be block storage via volumes to say here's here's storage just for that one application.
98
00:12:35.970 --> 00:12:36.180
Okay.
99
00:12:38.070 --> 00:12:39.480
Andy Whiteside: Have any comments.
100
00:12:41.970 --> 00:12:51.840
Harvey Green: i'm not yet as you kind of talked about this is a little outside of my box so i'm gonna let this to jarrod keep going and i'll jump in.
101
00:12:53.490 --> 00:13:02.940
Andy Whiteside: that's the question I mean I think we've introduced the concept, and the reason why I don't know that we want to go through how to do it necessarily jar right that wouldn't be good listening for our audience is there.
102
00:13:03.180 --> 00:13:05.850
Jirah Cox: We don't just summarize like the actual bits of code for sure yeah.
103
00:13:07.350 --> 00:13:09.870
Jirah Cox: it's it's the it's the technical, we can explore for sure.
104
00:13:10.980 --> 00:13:11.340
Jirah Cox: yeah.
105
00:13:11.670 --> 00:13:14.790
Andy Whiteside: Well let's look you want to walk through different pieces here.
106
00:13:15.240 --> 00:13:22.530
Jirah Cox: yeah to whatever the verbal spoken equivalent of like pseudo code would be from from our you know CS one one programming classes.
107
00:13:23.910 --> 00:13:29.640
Jirah Cox: In this case, you know this article is actually the fourth of a four part series talking about deploying open shift on new tactics.
108
00:13:30.540 --> 00:13:39.450
Jirah Cox: So as soon as you are a at this point, have a unix environment running open shift with the CSM driver already injected if if you're not up to that level right.
109
00:13:40.530 --> 00:13:54.420
Jirah Cox: The previous blog posts will get you there hey once you have all that right there, it will talks about installing installing getting something open shift coi and then helm, which is like a multi package manager right it's a way to install applications on to the communities framework.
110
00:13:55.770 --> 00:14:06.090
Jirah Cox: And then verify the CSI operator storage, so does my open shift environment know how to talk to new tonics know how to authenticate and then actually be able to request new storage provisioning.
111
00:14:07.050 --> 00:14:16.890
Jirah Cox: That let's assume that you get a yes, out of all of that, the way the the blog our blog or the author does as well, if not go back and try again or troubleshoot.
112
00:14:18.300 --> 00:14:26.520
Jirah Cox: Then it's all postgres right so some helm commands here for how do I install postgres right a database engine on to my Cooper daddy's aka open shift.
113
00:14:27.660 --> 00:14:28.920
Jirah Cox: environment so.
114
00:14:30.840 --> 00:14:33.270
Jirah Cox: install postgres verify that's up and running.
115
00:14:35.010 --> 00:14:38.250
Jirah Cox: That will be listed there and you're running pods and then.
116
00:14:39.720 --> 00:14:53.610
Jirah Cox: there's the commander for getting the PVC, which is the prison persistent volume claim, which is what storage have I requested for this application and there's a reference there and then the the blog posts also gives you a couple of scripts to run.
117
00:14:54.720 --> 00:15:06.600
Jirah Cox: scripts to say I lost my place here so so we create some data rights create some new tables within postgres so we're creating persistent data that we need to to you know.
118
00:15:07.920 --> 00:15:17.040
Jirah Cox: Have that application state right that needs to remain even after terrible things happen the application, how do I make sure that that data sticks around and is useful.
119
00:15:18.570 --> 00:15:33.780
Jirah Cox: And then another script that will snapshot that database volume every five minutes, so we created data and then after a couple minutes we'll have a few snapshots over time right, so how would I do data protection in a containerized application world.
120
00:15:39.030 --> 00:15:40.320
Jirah Cox: Okay, and then.
121
00:15:41.850 --> 00:15:44.160
Jirah Cox: Some more commands here given in the in the blog post article.
122
00:15:45.750 --> 00:15:53.220
Jirah Cox: yeah okay to run yeah right to validate the script the tables, to create the scripts run them yeah Okay, and then verify the entrepreneur in the background.
123
00:15:53.820 --> 00:16:03.330
Jirah Cox: So, then, we connect to the postgres database and it gives the sample credentials here don't use these credentials in production, please, and thank you, but for a live environment, you can use these credentials.
124
00:16:04.530 --> 00:16:07.110
Jirah Cox: And you'd see that those tables exists right that we created.
125
00:16:08.130 --> 00:16:10.830
Jirah Cox: As proof of like able to create data that should persist.
126
00:16:12.480 --> 00:16:26.880
Jirah Cox: So, then, we see our data everything's healthy and then also over time right, we should see that there's the article calls up five volume snapshots that have been created right so every five minutes is going to snap that stamp that application volume.
127
00:16:28.200 --> 00:16:34.110
Jirah Cox: So now we have our database running it's got data in it even even thinking a regular old school.
128
00:16:35.340 --> 00:16:40.860
Jirah Cox: fashion right take the containers out of it we haven't we have a database running the data data within the database.
129
00:16:41.430 --> 00:16:48.780
Jirah Cox: And we have some data pressure and snapshots of that data now we're doing it in a very fancy you know web scale modern way of doing it with containerized database.
130
00:16:49.230 --> 00:16:56.040
Jirah Cox: And CSI driver storage for containerized Apps but fundamentally right, we have a database with data in it.
131
00:16:56.850 --> 00:17:06.060
Jirah Cox: So now we need to you know we need our chaos monkey right we're going to cause failure and prove that we can recover from it, and with that we've preserve that application state as we do that right.
132
00:17:06.840 --> 00:17:18.030
Andy Whiteside: Well that's and that maybe that's the key for me is this is starting to make sense in terms of now, if that were to hit that container where the something were to happen to it.
133
00:17:18.600 --> 00:17:27.360
Andy Whiteside: We wouldn't we would have what we need to bring it right back up or is it is it right, make it available again instantly.
134
00:17:27.660 --> 00:17:37.470
Jirah Cox: yeah right what you know, depending on your availability model availability zones, but you know something bad happens, how do I reinstate that application right.
135
00:17:39.240 --> 00:17:39.540
Okay.
136
00:17:40.590 --> 00:17:47.970
Jirah Cox: Whether that's a recovery and the next cabinet over the next row over next data Center you know, depending on what you how far you've.
137
00:17:48.450 --> 00:17:58.980
Jirah Cox: replicated the data but also, I think this will get to this later on the blog post, we have snapshots over time as well right and it's a database, I mean, I know that we know, none of us know a database that's ever had like.
138
00:17:59.580 --> 00:18:10.920
Jirah Cox: An error caused by like actual human error, with it, but if something were to ever happen, the ability to go back in time, like five minutes before the air happened, it seems like it could be useful in certain certain circumstances right.
139
00:18:11.400 --> 00:18:12.270
Andy Whiteside: mm hmm so.
140
00:18:13.020 --> 00:18:25.920
Jirah Cox: So for this for this example, this walk through the chaos monkey is going to be, we, as the human or something going to uninstall postgres so no more database engine right that pod whole entire pod goes away from Cooper daddy's.
141
00:18:26.970 --> 00:18:32.580
Jirah Cox: And then delete that volume claim right, so there goes the storage for that application.
142
00:18:34.650 --> 00:18:44.100
Jirah Cox: So, then, to restore it right from the latest available snapshot there's a command here given to create a new volume claim a new persistent volume claim PVC.
143
00:18:44.640 --> 00:18:49.920
Jirah Cox: from the most recent snapshot and I won't read the code to you here, but you should look that up and use that.
144
00:18:50.850 --> 00:19:07.800
Jirah Cox: Once the claim is online now will reinstall a fresh copy of postgres basically from the Internet right like, if I had a brand new Cooper daddy's environment that had no cash pods and no images in my container repository I could still fetch this you know latest.
145
00:19:09.060 --> 00:19:23.820
Jirah Cox: postgres image fire it up, can I get to that to that storage storage layer and then the next man is we're logging into postgres and we're seeing what data exists in these tables within the database and of course we should see we have what we expect there.
146
00:19:25.200 --> 00:19:32.940
Jirah Cox: And then the last example given here right is what if we wanted to roll back to an earlier snapshot an earlier stage right of that database.
147
00:19:33.330 --> 00:19:44.640
Jirah Cox: We could actually create a new a new volume claim pointing to an earlier snapshot and we'd be able to compare those over time to say here's the earlier data earlier data, the older data, the newer data.
148
00:19:46.170 --> 00:19:58.470
Jirah Cox: Those can be different, and yet both access at the exact same time so, then I can even deploy you know, a second copy of postgres one to point to the first snapshot while once pointing to the last snapshot all the exact same time.
149
00:20:00.420 --> 00:20:00.570
Jirah Cox: So.
150
00:20:01.590 --> 00:20:02.910
Andy Whiteside: I think you've blown harvey's mind.
151
00:20:05.670 --> 00:20:06.570
Harvey Green: I am waiting.
152
00:20:06.810 --> 00:20:08.100
Jirah Cox: i'm sorry and or Thank you.
153
00:20:10.110 --> 00:20:12.240
Jirah Cox: Whatever whatever come Monday you're having Harvey there you go.
154
00:20:13.410 --> 00:20:13.980
Harvey Green: But.
155
00:20:15.660 --> 00:20:15.960
Jirah Cox: that's.
156
00:20:16.140 --> 00:20:17.640
Jirah Cox: that's kind of the state that I usually live into.
157
00:20:19.020 --> 00:20:30.090
Jirah Cox: But you know, because this is a key capability right, why does this matter it's because you know enterprises are wanting to build and run containerized Apps even if it's like, in this case postgres right, you know companies run postgres all day every day.
158
00:20:31.260 --> 00:20:38.610
Jirah Cox: That used to go to bed and a virtual machine and then tomorrow that can be in a container right same postgres same outcome for the business if it's a database.
159
00:20:38.910 --> 00:20:45.000
Jirah Cox: So I need to make sure that we maintain the same capabilities around data protection recover ability.
160
00:20:45.630 --> 00:20:56.910
Jirah Cox: That we had and the old world where it would be a database in a vm tomorrow with the database in a container but same capabilities right of roll back roll forward protect data recover data keep the business running.
161
00:20:58.020 --> 00:21:14.340
Andy Whiteside: Is this really just an example of your enterprise Linux workloads and that meshing up with new tannic hyper converge and all the beauty that goes along with that kind of all those things meeting and all of a sudden things become possible they weren't possible before.
162
00:21:15.690 --> 00:21:21.450
Jirah Cox: I think that's a cool way to think about it yeah for sure, I think there are some elements to that.
163
00:21:22.650 --> 00:21:33.450
Jirah Cox: With Linux I mean containers on windows or a thing as well, and then really what I think the mechanics part of the management magic we bring here right is that ability to say to sort of easily provide.
164
00:21:34.260 --> 00:21:45.270
Jirah Cox: Actually, you think, just like we did you know 12 years ago with the birth of hdi you know I create vm and they also have storage and it's Nice and simple Well now, I have containers, and they also have storage and it's all Nice and simple.
165
00:21:46.350 --> 00:21:55.410
Andy Whiteside: And this is taking containers to a world where it wasn't before and the applications applicability of it becomes.
166
00:21:56.520 --> 00:21:57.120
Andy Whiteside: extended.
167
00:21:57.810 --> 00:22:03.480
Jirah Cox: Well, anything well with with enterprise data protection right like snapshot and roll back roll forward.
168
00:22:04.710 --> 00:22:06.150
Jirah Cox: Combined with also.
169
00:22:08.100 --> 00:22:15.300
Jirah Cox: Not having to reinvent any wheels right like you could buy any thanks cluster you know we've all talked about the Foundation process here that thing comes to life.
170
00:22:15.780 --> 00:22:23.280
Jirah Cox: You know the morning and hits the loading dock if you want it to right if you've got your va lands sort of on the switches that clusters as online real real fast.
171
00:22:24.570 --> 00:22:27.930
Jirah Cox: You know now, it can be running open shift the exact same day.
172
00:22:28.470 --> 00:22:37.740
Jirah Cox: Oh, and by the way, can be running open shift with enterprise grade storage that afternoon and you're running applications and production by close of business right so very, very.
173
00:22:38.190 --> 00:22:52.590
Jirah Cox: dramatically short time to value compared to lots of other ways, you could do this right to like write your own application storage level but you'd be almost you know building toys for your toys at that point right versus like I just turn on enterprise grade features yeah.
174
00:22:54.690 --> 00:23:01.140
Andy Whiteside: yeah I get it, I mean it's not necessarily my wheelhouse but I get Why would be applicable if it if it was.
175
00:23:03.270 --> 00:23:12.630
Jirah Cox: cool I think it's I think it's very exciting stuff I I also, this is the stuff that I usually tend to save for my like lab hours you know late at night versus a.
176
00:23:14.970 --> 00:23:18.540
Jirah Cox: You know, things that i'm fully provisioned in myself but we're all we're all getting there together.
177
00:23:19.080 --> 00:23:19.440
yeah.
178
00:23:21.180 --> 00:23:23.280
Andy Whiteside: Armenia additional thoughts or comments on this.
179
00:23:24.090 --> 00:23:34.530
Harvey Green: No, I mean I guess the thing that I would say that I mean it's it's funny I think I continue to say this on the podcast The more that we do.
180
00:23:35.700 --> 00:23:43.830
Harvey Green: And the more that we highlight it just highlights to me how flexible this this new tannic solution really is, you can have.
181
00:23:44.460 --> 00:23:55.110
Harvey Green: You know something like this being able to run the the staple applications that are Linux based, and you know have that be your entire workload and not touch.
182
00:23:55.680 --> 00:24:14.580
Harvey Green: A whole separate thing that new tannic can do, and then you know the same for databases, the same for EC the same for just random file servers like this is, this is a hugely flexible system it's is hard to find holes.
183
00:24:15.810 --> 00:24:23.490
Jirah Cox: You can picture, a company that would like buy new tactics for it's you know, etc needs by new tactics for its application developers.
184
00:24:23.970 --> 00:24:31.380
Jirah Cox: And the developers go oh wait, it can run desktops to and the EC guys are going water containers right and it's like they're on the exact same platform yeah.
185
00:24:32.010 --> 00:24:45.870
Andy Whiteside: that's key I mean it's it's really cool and it solves a lot of business challenges and maybe there are different clusters and maybe in some organizations just all one big cluster doesn't matter totally yeah hey john to ask you about the syntax so this one right here, no i'm just kidding.
186
00:24:47.370 --> 00:24:48.300
Jirah Cox: i'm down man let's go.
187
00:24:48.990 --> 00:24:52.800
Andy Whiteside: Well, I was looking through they're trying to find one that I totally didn't understand to be honest, there wasn't one.
188
00:24:53.610 --> 00:24:55.830
Jirah Cox: Can I Google faster than Andy can ask the question.
189
00:24:55.860 --> 00:24:56.340
Maybe.
190
00:24:59.130 --> 00:25:06.300
Andy Whiteside: Alright guys well, I appreciate you jumping on and talking about containers and open shift and the ability to do stay for workloads and any chance well.
191
00:25:06.840 --> 00:25:09.780
Jirah Cox: cool appreciate it i'll talk to you next week have a good week.