‫Let me tell you about dry runs and diff's, which
‫is new stuff.
‫The last few versions of Kubernetes starting with 1.13
‫have this new option that allows us to see
‫what we're going to change before we change it.
‫We've seen that before.
‫I've showed you a couple examples earlier in the course.
‫But, this method of using it with
‫the apply command is new and
‫better. What we had in the past
‫was we had a dry run, but it was only
‫on the client. The client didn't actually talk to the
‫server to say hey, are these resources already there?
‫Do I need to recreate them, or are they going to be updated
‫or what's going to happen? Right.
‫That didn't happen before.
‫Now there's a server dry run option
‫that will send our YAML to the server and
‫compare, figure out what needs to actually happen
‫and then report back to the command line what's going to
‫change. Let's see that in action.
‫I'm in the K8s YAML directory like I discussed earlier
‫in a lecture, if you are in Docker Mastery's repo
‫and you don't have this directory, then
‫you need to do a git-pull to get the latest updates.
‫This is a file that we've seen in a previous lecture,
‫app.yml. This is a service, plus
‫a deployment, in one file.
‫It's technically two resources are created with one
‫apply command and they're related.
‫The service uses a selector, which we haven't talked
‫about yet. Selectors are how one object
‫finds the resources that it wants to talk to
‫or do something with.
‫A service needs to talk to pods, so it needs to find
‫a way to get to those.
‫It uses selectors as essentially
‫pattern matching to match the labels the keys and values
‫there. If I did the traditional dry run here,
‫then all it would do is the client would look at the apply
‫and say, yeah, I'm going to create these objects.
‫All right. It's always going to come back and say created.
‫That's because the apply is not
‫very specific. If you were using an update, or a create, or
‫a delete command, which again I don't feel like
‫is a very DevOps-based workflow.
‫Those commands would just do a dry run and you know the
‫update one would say yeah, they're both going to be
‫updated. But, it doesn't really know on your cluster,
‫right. It hasn't talked to the server to figure that out.
‫We want to try the server dry run which
‫is enabled by default on anything 1.13 and newer.
‫When I do that, it will then go talk to the server and
‫give me a proper response.
‫Let's go ahead and create this.
‫I'm going to take off the server dry run.
‫This will create the two resources, the deployment
‫and the service.
‫Now, if I hit the up arrow and go back to server dry run,
‫you'll see that it says unchanged for both of them.
‫It's not telling me what changed or
‫if there was something that was going to change what it
‫would be. It's just telling me that a resource will be
‫changed or not changed. It's sort of a toggle, yes or no.
‫What about getting the actual difference between
‫what we want to give the server and what the current
‫status is of our resources.
‫That is the kubectl diff command.
‫If I simply give it a diff instead of an apply,
‫it will compare the YAML I have to
‫the spec that is in the servers
‫now running. that status comes back, and it will do
‫a diff on that. Let's do that.
‫It'll say nothing because there is no difference.
‫But what if we go change the YAML?
‫What if I change the replicas to two?
‫Then I add a label in the metadata and
‫I'll give it something like...something like.
‫Servers dmz.
‫I made it up. Doesn't really matter.
‫Then we have the replicas of two.
‫If I do that same diff, it comes back with
‫the pluses and minuses.
‫If you're used to reading diff's, this makes perfect sense
‫to you. If you're not used to diff's, the minus
‫means that line would go away.
‫Then these lines would be added.
‫Then down here, it shows you what line
‫and what character in the line that this is
‫being removed.
‫This is being added.
‫It's keeping the YAML formatting, which is nice.
‫It's letting us know that multiple changes are happening.
‫Great. Of course, this isn't really doing something like
‫a canary, or test deployment or anything.
‫It's not trying to do the thing and then seeing
‫what the result is. It's really just looking at the
‫specification it has on record, and the specification that
‫we have on our disk. Check for
‫more info on that on the resources links.
‫It's a blog article from the Kubernetes team on the
‫future of these and how they're going to play out as they
‫come out of beta. Remember, these features right now are
‫beta, at least in 1.15 they are.
‫Hopefully with that, you can create your own workflow
‫for creating YAMLs from scratch, Managing
‫the specs in those YAMLs, and then using the apply command
‫over and over to make your changes.
‫That's a much more DevOps friendly infrastructure as
‫code type of way of doing it.
‫Everything you do is documented, hopefully in Git.
‫So, you're hopefully making a git-commit for each change
‫you make in your YAML before deploying it to the server.
‫Then you have that nice documentation in Git,
‫as well as the documentation when you do something like a
‫diff to see what you have versus what's actually running.