Continuous Delivery Foundation Spinnaker Summit 2022 - Detroit, 4 Nov 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Introducing Spinnaker for GCP Serverless Deployments with Cloud Run and other GCP... Kiran Godishala

Description

For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/

Introducing Spinnaker for GCP Serverless Deployments with Cloud Run and other GCP Related Enhancements - Kiran Godishala, OpsMx

Would you like to deploy serverless applications in GCP using Spinnaker? Cloud Run is a fully-managed compute environment for deploying and scaling serverless HTTP containers without worrying about provisioning machines, configuring clusters, or autoscaling. Spinnaker now has native support for Cloud Run for deployments. This talk will discuss the features built into Spinnaker for Cloud Run and other enhancements made over the past year for the GCP environment.

A

Hello, everyone welcome to Spinnaker, submit 2022 I'm, going to talk about introducing Spinnaker for gcp serverless deployments with Cloud run and other gcp related enhancements. Yeah. That sounds pretty long. Title I didn't mean to summarize everything in the title, though: uh I am gorushala from option X, and these are the topics I'm going to cover today.

A

So Cloud one introduction and then we'll see, Cloud run resources how they map to Spinnaker in the implementation. And then we see some Spinnaker enhancements related to the gcp, the Google cloud provider and then will be C. And then we see the cloud run deployment demo.

A

So let's get into this, so Cloud run introduction. So what is cloud run? It's a managed compute platform from Google Cloud to run the containers, so it's a serverless. So all you need to supply is the container image and the underlying infrastructure will be taken care that in that includes Auto scaling. So you need to specify the minimum and max number of container instances needs to be run and it will take care of Auto scaling, scaling it up or down based on the incoming requests, and the deployments are pretty fast.

A

So when you supply, when the container is not so big, the deployment happens in seconds, not even minutes and it's a PayPal use. So you need to pay only for the request that was served.

A

You need to pay only for the CPU seconds that were used and when there are no requests, so you are going to pay nothing and the use cases. I have listed some, so the cloud run can be the cloud run. Deployments can be used for a website, so you can expose API endpoints and you can trigger them and for the asynchronous tasks, so it can be used as a backend for the mobile apps.

A

It can be used as a I mean it can receive web hooks upon which you can do some tasks so and there can be many more use cases.

A

So this is a very interesting uh service from Google Cloud platform.

A

Okay, so Spinnaker is a truly multi-cloud CD tool and as far as Google is concerned, there are two Google services that were already part of Spinnaker. One is a Google compute engine and another is Google app engine and Cloud run will be third.

A

So when we create, when we add a new cloud provider to the Spinnaker, we need to consider certain aspects. uh So what is the account and what is the load balancer, so the corresponding resources in that new cloud provider? We need to first uh figure out and then we map accordingly.

A

So here uh for spinner in the Spinnaker technology, account means the representation of the cloud provider with the credentials and other info that is needed by the Spinnaker in order to perform certain actions in the 12 process, such as deployments or any other calls needed in that process.

A

So for the cloud run, the account is nothing but the gcp project. So we provide the project project, ID and credential suggestion, um so that will be the account and for the load balancer.

A

uh So, first of all, in the cloud run, there are two main components: one is a service and another is a revision.

A

Service provides a unique endpoint uh to the unique endpoint to the unique endpoint to the containers, and it also takes care of the underlying platform scaling up or down based on the in incoming requests and so service is mapped to the load balancer in Spinnaker, and then we have server group. So in Spinnaker server group means it's. A collection of instances of the running software and the running software in Cloud run is at the containers and uh it is represented by revision.

A

So revision contains group of container instances, so you can have multiple revisions within a service, and traffic can be split across those revisions, so Cloud contribution will be servable, and then you have instance, which is cloud run contained instance. So these instances will be running in the revision.

A

So these are the mapping uh resource mappings we considered for, while creating while implementing a new cloud provider in spin across okay. Now we see some of the Spinnaker enhancements related to gcp.

A

One is a Google secret manager which is implemented as a secret engine now and others. The remaining three are related to Google compute engine cloud provider, ADC and impersonation support external Google accounts, Auto scaling enhancements, so we will see briefly what these enhancements are.

A

So uh Google secret manager, so we already have S3 and GCS as the secret engines. So what are these secret engines with respect to Spinnaker, so spinach separates the secrets from the configuration so in the configuration you may need to supply certain Secrets. But how do we deal with it? So spinaka provides a end-to-end secret management by providing these by by implementing the secret engines so existing or S3 and GCS. So you, you would add your secrets in say S3 bucket and then refer them in your configuration in certain format.

A

So similarly for uh Google, secret manager, you add your secrets in the Google secret manager and then refer in your spinal configuration as shown in this box. So if it is a text, you will write encrypted, Poland, Google secret manager, and then you supply this exclamation P colon and the project number and then your secret ID and then secret key secret is optional. So if your entire secret is the text you wanted, then you don't need secret key.

A

If it is a Json file and within the Json, a certain key value you need, then you use this CZ key and also the Google secret manager uh provides the versioning of the secrets. So if, for any reason, if you wanted to use previous versions other than latest, then you can use, you can add this vehicle and secret version.

A

So if you don't provide this, the latest version will be considered similarly for uh using encrypted files for any credentials or any other files needed. Then you use this encrypted file and this notation. So this is uh already implemented. It is uh recently added to the Spinnaker very recent release.

A

Okay, next is ADC and impersonation support. So now we no need to provide uh credential suggestion if we use ADC, so only application default trading points are sufficient, so the if, if the Spinnaker is deployed in either any of the Google platforms like ec2 or gke, then uh they provide application default Vanessa. Of course there are many ways of providing ADC. So if if these ADC are supplied and if they have necessary permissions to impersonate, then all you need is to supply the impersonated service account and its Google Cloud project.

A

So this impersonator account need not be part of the same account same project. It can be a different project as well still using the ADC. The Spinnaker will be able to deploy into that project.

A

So actually these features were present but uh never worked because of some gaps. So now those were fixed. So now you can use a halyard for uh supplying these impersonated service account and project and external Google accounts. So this is basically Dynamic account management for Google accounts, so you can supply Google accounts externally.

A

So as of now, there is no other way but to add the accounts through hell config. So all the accounts uh will be part of the hell config and if at all, you want to add or delete any account, so you need to bring down the spin account then add these make the modifications and then restart. So with this implementation, you can have the accounts somewhere else which you can modify and then, after a while Spinnaker will identify those and load them refresh them.

A

So so you can have the accounts in any external source, and that can be uh that can be loaded through a plugin. So you need to have a plugin to make Spinnaker know where the accounts are. So we have developed plugins for GCS and git sources, so that means you can have a file in GCS bucket and use this plugin and the supply.

A

A certain configuration to make spinner kernel know where the account is then Spinnaker will load those accounts, if you, even if you modify the file with with any new accounts or delete the existing accounts. That will be refreshed in this minute.

A

Similarly, with the git source, so you can have a accounts file in uh in a git repository and then use the git plugin. Then that will be loaded and finally Auto scaling enhancements. So Auto scaling feature itself was not new, so it was already present, but with the feature flag.

A

So only when the feature flag is enabled that will appear that will not at the time of creating the server group or creating an instance group, but after it got created, then you can go and enable auto scaling, Supply, Min or max number of instances.

A

So now that got changed, so it is now part of the create server move. That means at the time of creating the server group, or instance group. uh You can choose Auto scaling and you can specify that and now scaling schedules are also added.

A

um So that means, let's say for um let's say, for if it is an e-commerce project and for the Black Friday there will be more sales, so you can, uh you can add a schedule for so and so dates. Then the minimum number should be this much so max. Is these many so that scaling state is either now and the custom metric utilizations is updated with more fields, and so previously only few Fields were there. Now it supports um all the fields that are available in the Google console.

A

So these are the Spinnaker enhancements related to gcp and let's see the demo of cloud brand deployment.

A

Okay so I have created, I have added an account to my Spinnaker, and so it's a it's. A cloud run account and I have I, have created a server group and.

A

So this is the server group and it has a minimum uh one instance and Max. This is for the auto scaling purpose and it has the instance and so instance. uh Usually it doesn't have much significance with the cloud run, because these are fluctuating based on the request. It will go up and down, and so we cannot completely rely on the instance, so there will be one instance all the time, and then you have a load balancer here uh so which is nothing but the service, and this is the service endpoint. We can access.

A

This I mean if we have the required permissions. We can access this, and if you see there is only one revision, that is what we are seeing here: one division having hundred percent traffic and let's see the pipeline, so this is a simple pipeline having a deploy stage and uh so okay, so I forgot to mention.

A

Loudtron uses K native manifest. So if you see here, it's not a kubernetes manifest, but K native manifest, and so it is an open standard can be used on kubernetes or any other uh any any other container technology.

A

So main things to identify to to observe here are the image so right now, I configured it to be taken from the parameters. I will show the parameter, and then there is a service account and this service account should have the required permissions to deploy a service, and so this is basically uh to manifest. We are going to deploy.

A

We are going to deploying to Cloud run, so these are some of the details and then so here, I provided a sample image here so which we're going to use Cloud run. Revisions are immutable, so that means, even if you don't, you didn't make any change to the image. So it creates a new revision, no matter what, once you create a revision? That's it! You cannot modify that one. So if you make any small change that will create a new division.

A

So what I'm going to do now is uh start this so I'm going to give the same image and we'll run it.

A

And meanwhile I will show you this one. So.

A

This is the demo project a multiplication, so this is the service name.

A

A

So demo spin somewhere, so this will be the cluster and it creates another load balancer or the service. With this name.

A

Okay, so the pipeline executed successfully, so it took less than um 80 less than 20 seconds and if I refresh this one.

A

Yeah so it created just now- and you see here, the traffic is zero percent. We can edit the traffic uh um using using another stage for editing any load balancer stage so, but we will do that now through the load balancer now, so you have added load balancer.

A

So if I add so it recognized that another revision here so if I make here say, 10 perfect allocation must produce some 200, so I'll make it 90. So this will make 100 now, if I update the traffic will be split across these two images according to this percentage.

A

So as of now, you have 100 in the first revision and now I'm, making it 90.

A

And you can see meanwhile, I'll show you, so this is the yaml for the service. You need to uh camera file, so it shows. As of now, this revision has 100 perfect.

A

And we checked, you can check the again before the revision as well, and now, let's see here, okay, so.

A

So we have edited the transit here. You should be seeing the traffic split 1910 there you go. So this is a new revision and we should be seeing that here as well.

A

Yeah, so we even receive uh 10 of the traffic and uh receives to 90.

A

Yeah yeah, thank you.