keptn Keptn Tutorials, 26 Feb 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Tutorial - Migrate a Keptn 0.7.x service to a 0.8.x service using keptn-service-template-go

Description

Migration Guide: https://keptn.sh/docs/0.8.x/integrations/migrate_from_070_to_080/#distributor
Keptn-Service-Template-Go: https://github.com/keptn-sandbox/keptn-service-template-go
Keptn spec 0.2.0 / CloudEvents: https://github.com/keptn/spec/blob/0.2.0/cloudevents.md
Litmus-Service: https://github.com/keptn-sandbox/litmus-service

New Shipyard File Examples: https://www.youtube.com/watch?v=n9eIMLO0THQ

A

Hi everyone and welcome to this video in this video we're going to show you how to migrate. Your existing captain 0.7 service to a captain 0.8 service by example. So, uh first things. First, we have a tutorial on that or actually it's more like a guide, not a tutorial, and it's available in our docs I'll, put the link in the video description below don't mind this url up here. It's just a preview url. You will get the final url in the video description.

A

So within that document here within that guide, we go through a lot of details like what has changed in cloud events, so we're using cloud event: spec 1.0. uh What has changed in captain cloud events? We now have dot, started, dot, finished events and dot triggered events that you need to take a look at and basically all our cloud events have changed.

A

Almost all of our cloud events have changed so, for instance, if your intention was to listen to a cloud event to start tests in captain 0.7, this was a deployment finished event and with captain 0.8 we've added a dedicated test, dot triggered event same for deployment. We have a deployment dot triggered. We have an evaluation triggered, so each of these now are dedicated steps that are being triggered and that you can listen to with the distributor.

A

I don't want to go into too much details here. If you're interested in the new cloud events there's a video uh in the in this channel, I will link it in the video description below uh where we describe the new shipyard format and what events we have for now. What is important for you to know is that you should react on a triggered event, for instance, deployment triggered, and you should acknowledge that you are processing this event by sending a dot started event of the same type and eventually sending a dot finished event.

A

This is something that you need to implement in this service. Okay, so let's just go directly to our migration guide. Here. This is the guide regarding go utils, and this is where you really need to take a look at so to start, what you would you do is you would update your uh go utils library by saying go, get github.com go your deals here.

A

This will change, go modules and go some, and if you run a go, build dot right now, you will get some errors, as we do have some references that don't exist anymore, okay, so far, so good um by the way, we're taking a look at litmus service here. So if you're interested in that, you can find it here on captain sandbox I'll, also put it in the video description below litmus service is a quite a simple, easy service that we have in our captain. Sandbox.

A

It essentially listens to two cloud events and that's the deployment finished event and when deployment finish is received, it starts some litmus chaos tests and once a test finished is received from another service, it just stops the litmus chaos experiment, it's quite a simple service, but, uh to be honest, most microservices in the captain service domain should look like this or should be rather simple than complex.

A

Okay. So what we did here is we tried to compile it. We saw it didn't work, let's look in the code, why it didn't work and we're going to start in eventhandlers.go.

A

What we actually need to do here is we need to upgrade our captain library or actually, we've already upgraded it using goget, but we need to use the the new version of it. We also need to update our cloud events uh library here and then we need to change some code, and this is essentially described in here.

A

So, for instance, instead of this captain lip we're now using the captain lib version zero, two zero, that's indicating um that we're using the zero two zero speck of captain and when you do that, you also need to use it so what's changed here is that we don't use captain.captain anymore, but we use captainv2.captain.

A

In fact, let's remove that piece of code here, because it's uh it's not needed, we don't do configuration changes we want to handle the deployment finished event. Okay, the next thing that has changed is we don't handle a deployment finished event anymore.

A

This is actually shown up here in this huge table. If you, if your intention is a deployment, has finished, start tests, you used to listen to deployment finished event, but you should now listen to a test.triggered event, so we're going to rename this and call it handle test trigger event. All right, then. Obviously this is also wrong. The data. This is no longer a deployment, finished event data. This is now a captain. V2 test triggered event. Data.

A

Which is not working yet because we might need to compile it once, let's see yeah now, it's working test triggered event data. Here we go the the the data in it are basically very similar than before. So you have project service stage and whatever else you need, but it's a different struct now and it's it's a little bit easier to use now. Okay, so the next thing we need to change- let's just go down here to go.

A

Utils is the cloud events library which is now cloud events sdk go v2 and we just need to change the import up here, all right cool and, let's take a look anything else to change yeah the finished event, but so far so good. The event handler looks good, uh but there are some more things that we've improved. You know so, for instance, the resource handler here we don't need it anymore. We can replace this code where we pass project service stage, etc. With this code, it's called captain resource content.

A

Sorry I'll just copy it from here. My typing is horrible. Today, there we go uh we're gonna fetch, my captain, dot get captain resource, uh we're gonna, fetch the litmus experiment, file name there we go.

A

We don't need to initialize the resource handler anymore. There we go, um we can this needs to go. This is now string, so this is now fetching a resource and we're fine. So that's a lot easier.

A

Okay, so, what's still left to do is something that I already mentioned. We need to make sure this service acknowledges. It has started the execution. So here we need to send a started event, and this is handled by go utils. My captain send task started event. Here we need a captain v2.eventdater which we can leave empty for now and the service name, which is a constant. I still need to introduce I'll do that quickly.

A

You can either do it here or in your main.go I'll. Just do it here. For now there we go sorry, it's there. So there we have the service name now and obviously, when we send the task started event, we also need to send the task finished event, so we can scroll down in this case it was here.

A

um We need we need to always send this event, so we don't need this if anymore, we'll just send this event now, and here this gets a little bit more interesting, because now we should populate status, which indicates the status of the execution and I'd say in this case. If we got that far, it was successful and the result which indicates the actual result of the execution so positive or negative, or pass or fail, and we already have that here with the verdict, so we can initialize. Our result here result is a captain.

A

V2 ris result failed by default, and if the verdict is pass, then we can say result equals. Captain v2 result pass cool. uh We just passed this result down here and we can also add a message here now. This is also new. uh We could just say uh litmus chaos tests finished.

A

I can remove that. We should, however, catch whatever is coming here. uh This is a string that we don't need to catch right now, but the error is interesting and we should return the error in case there is one cool and with that uh we have migrated this little function. There's just one more thing that we need to do and I'll copy paste this, because it's easier what if we return an error at one point, so, for instance, here we return an error that we couldn't find the litmus experiment, file name.

A

This is something you need to pay attention now in captain 0.8. You should never just return an error. You should always send a task finished event in this case, did I say task started below sorry, I meant to say, send task finished there. We go so send task finished event. Here, it's the same signature. um I don't have a result yet so here I'm gonna put in the result failed and status.

A

Sorry status, error. There we go and the message is not gonna be litmus chaos test finished. The message is going to be the log message that we have created above so we are sending a task finished event with the log message above, and this is eventually shown in captain's bridge, so the user actually gets notified hey by the way, you're missing this file in your project, and then we should just return an error or actually even go like this.

A

If the error from the send task finished event is, is if there's an error present, then we need to return this error, and else we can just uh go on and return the locked message error, but it's really important to never just exit your service and yeah.

A

I think this is not needed as well. We can remove that cool. I think this function is is done. Then. We have also have the handle test finished event here that we need to migrate. So also here we want captain b2.captain and we want captain v2 and it's not called tests finished. It's now just called test finished and I think other than that we don't need to do anything.

A

um I'm just seeing here is a to do basically, so we want to react on test finished event only if they're coming from someone else but the litmus service- and we now need to do that, because we're always sending the task finished, which is a test finished in in reality. So here we're just gonna check if the incoming event dot source is not equal service name and then we're just gonna return. Sorry, if it is equal, we're gonna, return, nil,.

A

So when, when we call this send task finished and we enter this, then this one will make sure that we don't execute the code, because what we do here is deleting the chaos experiment, and if we got that far already, then we don't need to delete the chaos experiment. It's already gone, but, to be honest, it's not needed uh in all cases, so yeah, okay. So now we have two functions here. That's the handle test triggered and handled test.

A

Let's rename this to handle test finished event. um I think the code below just has some empty function. Handlers, I'm gonna, remove them. We don't need them, except for the execute command. We need that, okay, so our event handlers is done. We now need to take a look at our main.go, so our main.go here is now also full of errors and we could fix them. We could do the same thing like import, the correct code, etc, etc.

A

But, to be honest with you, unless you have something very specific, you can just go to the uh captain service, template and use the main dot go file from here and just redo whatever you need to do like the litmus experiment file name. So let me just make sure I'm not losing anything.

A

A

Litmus experiment, file name, I'm just saying we have the service name here, so I'm just gonna rename this to litmus service and I'm gonna remove the service name from my event, handlers now, because it's duplicated cool and then let's take a look. What do we need to pay attention here? We basically have all the cloud events that we can listen to all the types which we can construct using captain b2 get started or get finished or get get triggered event type.

A

We can essentially remove everything that we don't need, or we can just remove everything and write it from scratch. That's also fine, I'm just gonna remove most of it and just keep one thing for me to work with all right. Let's just remove this one and go here there we go. So what do we need to do here? We need to rewrite this a little bit.

A

We want to react on a triggered event, but it's not the remediation triggered it's the test triggered so we say, captain b2, get triggered event type and captain b2 test task name. I also like to write it out here just to have it in my mind, don't need the lock statement.

A

Then we need to initialize our event, data which is now at test triggered event, data object or struct. If you look at it um it's I think I need to compile it once so. We can actually see what's behind it there we go. If you look at it, it contains event data. It contains the test trigger details and it contains test trigger deployment details.

A

um It's really a very simple structure. You can write your own structs if you want to. If you just have your own payloads here, that's fine, then we're going to parse it there's a new function that we have in main.go that basically just tries to parse it and locks a fatal error in case something goes wrong.

A

uh Then we need to call our handle function, and this is now the handle test triggered event. uh We're done. That's it so! Well, one more thing: we need to handle the test finished event as well, so we copy the code instead of get triggered, we're gonna, call get finished event type and we have the test finished event. Data here and we're going to call handle test finished event which we have implemented and with that we should be done, and I can compile my code. I guess yep, it worked cool.

A

There is one more thing now to pay attention to and that's the kubernetes manifest for this service, which you need to take a look at so first of all, this is also described in the migration guide. So if you go through the migration guide, you see all the things that we've shown like sending cloud events sending a started and finished event, fetching resources and yeah, and the next thing that's also in here is: we need to adapt our distributor.

A

So, first of all, our distributor image is now zero. Eight zero, because this is for captain zero, eight zero. um Then second, we are gonna. Do we have reduced our resource requests, um see here like to 16 25, 32 50., so 16 megabyte is enough. 25 milli cpu is enough. 32 megabytes and upper limit is enough, and 50 m cpu is also enough. Here, that's more than enough to run the distributor, it's not very complicated, so this should be fine. You don't need to do that, but I highly recommend doing that.

A

But what you need to do is changing the pub sub topic, because here you used to subscribe to the old type of events, and you need to change that to the new ones. You could just do an sh dot, captain dot grader, which would subscribe to all events, but that's a lot of overhead and I just recommend to be very specific and say you want to subscribe to.

A

Sh.Captain.Event.Test.Triggered and sh.captain.event.test.finished in this case, and that's it cool yeah. I think we're done with migrating the service thanks for watching and listening. If you have any questions, please hit us up on slack or via github, or leave a comment in the video below. If you want to also if you like this content, if you like this kind of content, please, like this video subscribe to our channel, leave us a message, and this will help us in getting more videos like this up and running on youtube.

A

Okay, thanks and see you soon.