keptn Keptn 0.8.0, 26 Jan 2021

Previous Meeting

Next Meeting

⏯

youtube image

►

From YouTube: Tutorial - Keptn 0.8.0-alpha - Shipyard Examples

Description

Previous video: Keptn 0.8.0-alpha Shipyard spec: https://www.youtube.com/watch?v=pGS5Ebbuc6s
Keptn 0.8.0-alpha examples: https://github.com/keptn/examples/tree/release-0.8.0-alpha
Keptn service template (GoLang): https://github.com/keptn-sandbox/keptn-service-template-go

-

Learn more: https://keptn.sh
Get started with tutorials: https://tutorials.keptn.sh
Join us in Slack: https://slack.keptn.sh
Star us on Github: https://github.com/keptn/keptn
Follow us on Twitter: https://twitter.com/keptnProject

A

Welcome to another video in this video we're going to talk about the captain 080 alpha shipyard by example, if you've missed the previous video we've already explained a little bit in the previous video on how the shipyard specification looks like and what you can do with the shipyard files and how the cloud events look like, etc. So uh go watch this video if you haven't, if you have then enjoy this content, because here we're going to show you how to use the shipyard by example.

A

So, with the first example, we're going to start with one of the major advantage about advantages of the shipyard file which is customization.

A

So let's say this is our existing workflow or existing sequence in the terms of shipyard, it's an artifact delivery for our dev stage and we have deployment test, evaluation and release.

A

What we want to add is a database migration step example given for django projects, laravel projects, but also various other projects, and we want to add it after the deployment step and before the test step. So how do we do that? We actually add a new line here called dislike, name: name: migration.

A

We add properties like database perf test or whatever comes to your mind that you need as a property here and that's about it in the shipyard file. So if you create a new project and add the shipyard file, then this is what it looks like, and this is what a migration.triggered event looks like that's being sent by shipyard controller.

A

Essentially, uh you get the deployment data from the last deployment event in here and you get the migration data which have the properties as defined in your shipyard, and you get the regular properties of a captain cloud event like project service stage and down below. There is some more properties like labels, id spec version, etc.

A

All right so what's left to do is to implement such a migration task or service, so to say, because this is obviously a cloud event, and this is a step that is not coming from captain. This is a step. That's application, specific. We cannot take that away from you, unfortunately, but lucky for you. This is quite easy to implement. With our captain service template go link is down below in the in the description of the video. If you want to take a look at it, so what do you need to do?

A

Is you need to import our go? Utils, library and within that library we have the version 0.2.0 package, which contains event data and some captain helper functions and yeah? We need to define immigration triggered event data. Well, we don't need to, but it's best practice that you have a type for it. This includes the captain event data and the migration data, and migration itself just contains database, which is a string and that's about it. So this is just the mapping from the captain cloud event into a go struct.

A

So if you look back here, we have the uh the data, that's captain cloud event specific and we have the migration data here, all right and then somewhere in your process, captain cloud event function, that's provided by the service template, you would have a switch for the event type and you would say if the event type is of migration, even better triggered migration. This is a helper function here and essentially this helper function just converts it into the string. Sorry sh.cap.event.migrationtrigger! That's about it!

A

If that's the case, what you need to do is you need to pass the captain cloud event.

A

It's just the json dot, unmarshall, it's being wrapped here, and the information is stored in event data, and then you call your handle function here. With the captain helper functions, the incoming event and the event data within the handler function, then you need to send a started cloud event, a finished cloud event once you're done and in between you run your migrations.

A

I've left out the implementation details for this function, but this could be a syscall, for instance, to cube ctl, exec some service and call, for instance. This is a python project here, manage py migrate on that service.

A

All right! That's about it! That would be your migration step. uh If you want, we can provide a in-depth example. So just leave a comment if you're interested in that and we'll have a look at it.

A

The next example I want to take a look at performance tests, quality gates and how to link stages together. So in this example, we want to create a simple shipyard for just running some tests or performance tests and for evaluating the results, and this would be the shipyard. So we have a single stage called hardening with a single sequence called evaluation, and this sequence consists of the task test.

A

With the test strategy set to performance and a task called evaluation, the test task could be executed by any performance testing tool. We are shipping geometer with captain, so for by default. This will be chameter and evaluation itself is a built-in task of captain. That's been executed by our lighthouse service and will perform an evaluation based on the monitoring tool that you have in the background. So this could be prometheus. This could be dynatrace or any other monitoring tool that is implemented.

A

um That's quite simple, actually, there's nothing more to say here, but let's extend our goal a little bit to make this more interesting, we'll add approvals and we will add another stage.

A

So if you want to add an approval, this is also a built-in step of captain and you just need to add the task called approval here. That's about it and if you want to add another stage, you just add another stage and you can link the stage to the hardening stage by defining one of the triggers, and in this case the trigger would be hardening dot, evaluation, dot finished. So it's the previous stage, name dot previous sequence name, it's the same sequence here and dot finished uh by default.

A

I think that's the default behavior anyway, but if you want you can be explicit and write it out and in the production stage we then have the sequence called evaluation. So it's the same name, and this has the tasks test and evaluation.

A

In my opinion, it doesn't make sense to also add the approval step in here, because you only need the approval step up here and you don't need to have another approval down here, but it would be entirely possible.

A

Okay. So far about this example, then let's go to our last example: multiple parallel stages, which is also one of the the key features of a new ship shipyard format. This wasn't possible with the old shipyard format.

A

Obviously so we want to have the stage hardening pre-prod production for customer a and production for customer b, so far so good, but we want to be able to have the rollout in parallel to customer a and customer b, so we have hardening pre-prod and then a and b it just splits at this point, and this would be the shipyard file for it. So you define your stages. You just list them down here, hardening pre-prod customer, a customer b.

A

You define your sequences, for instance, in pre-prod we have the sequence, artifact delivery and some tasks that we are not going to go through about right now and then for customer a we defined, the trigger is preprod dot, artifact delivery, dot finished. So it's the stage name of the stage that it should be triggered by dot the sequence name, dot finished and for customer b we just copy it. It's the same: trigger prepro dot, artifact delivery, dot finished. So with this we have the stages split in parallel and the tasks will run in parallel.

A

um Obviously this requires that the services that you are talking to can run tasks in parallel. So, for instance, if you have a deployment tasks using helm service, then this would mean there is two helm charts that are being deployed in parallel, but this shouldn't be a problem all right and with that we are actually done with our examples.

A

um That's just a very, very, very simplistic view of what is possible with the new shipyard files. If you have any questions or ideas for other examples, please write them in the comments or join us in our slack channel and ask us there and yeah. So if you enjoyed this video, please like this video and subscribe. If you want more content like this or if you want to get notified, if new videos are being published.