GitLab Solutions Architecture, 21 Aug 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Lightweight Service Registry with GitLab Repository

Description

This lightweight service registry idea leverages Auto DevOps while also providing dynamically defined environment URLs

https://gitlab.com/poffey21/service-registry

A

Hi, this is tim poffenberger, I'm a solutions architect with gitlab, and I wanted to run past a few approaches for the construct of microservices and how to share url end points between different projects within gitlab, there's, a few different options, and I kind of wanted to share what options that are out there today and potentially a lightweight service registry tool, utilizing auto devops and a gitlab source code repository so historically uh environment variables.

A

Anything that you need needed to be you know somewhat secret or environment scoped get lab. Ci variables are pretty useful here and what you can do is in the gitlab settings. You can store secrets and, if you prefix anything with k8s underscore secret underscore and then the variable name, this will everything after the k8 underscore secret underscore will get propagated into a autodevops environment.

A

So if you ever want to pass in environment variables in and store them into your running applications on kubernetes, this is a really simple way to do this um and one of the nice things is. You can scope these by environment. You can protect them and there's a few different options there as well. So you know this: one is for all review, apps, let's go ahead and point a particular url endpoint to this- and this is you know, manually defined anytime. You want to update this you'd have to update it within the gitlab ci variables.

A

Another option is you: could we're building out or continuing to build out integrations with hashicorp vault and there's nothing preventing you from you know, storing secrets or environment urls within hashicorp vault and then uh based on the jwt the jot token, as well as the location of what you're attempting to get vault could return. Those things for you as well.

A

Gitlab also provides you the ability to have helm charts. So by default, your helm chart provides you your cont. Your docker container um is uh running inside of git lab and then or inside, of a kubernetes cluster, and then there's also a postgresql database. That's provisioned! um Alongside of your your application as well.

A

So that way, um it's there are, you know external services, but there's nothing preventing you from defining a helm chart that has all of your other project repositories, um ref or all of the the containers from your other projects referenced within that helm chart as well.

A

So uh you know upon a review app being provisioned your you could deploy into a single name, space uh containers from multiple projects and have them inter interconnected and talking together, and we have quite a few environment variables that you can override, but from from the idea of overriding a helm chart, these are probably the most important ones available.

A

Additionally, you can always roll your own cube cuddle commands, so there's nothing preventing you from utilizing cube cuddle rather than auto devops to actually, you know set up your your environment, how you see fit and one of the nice things is you're, not name space, uh you tied to a particular namespace and you can get creative there as well idea behind this lightweight service registry is uh really you know. Let's take a for example, you have multiple project repositories and some of those project repositories have long lived services.

A

So we have project a project b and project c and there's dependencies between these projects. Project a relies on project b and project c. Project c is a fairly long lived project. It doesn't see a whole lot of changes, so so it doesn't make sense to you know continuously be developing, but project a and project b. There are some interdependencies between those two so often times what the development teams do is they'll create a feature.

A

Branch uh called feature, one two three, and um that that naming convention will be consistent across all the different projects, so branch uh project days branch, feature 123- is synonymous with project b's feature one two three. Ideally what would happen is um this environment. I'm sorry. This branch would automatically provision a review environment and get lab by default. Utilizes this branch name as the environment name, and so you have this project a and it's being deployed out to there's a review environment deployed out to feature one.

A

Two three and project b also has a review environment called feature. One two three and project c does not it's only on the master branch. It has no feature branch. So, there's a staging environment and a production environment.

A

Now, ideally, we could automatically wire up this review app to point to the review environment associated with feature 123 for project b and subsequently, given that there is no review forward, slash feature 123 environment, we'll just go ahead and rely on staging so setting some sort of priority in terms of when to use which environment and maybe even if there wasn't a staging environment, we would automatically go to production.

A

So this is a simple project uh called um it's a a django web application, so it's written on the django framework and uh you can see that this project just has autodevops enabled, which makes things really simple. Another thing that I'm doing here is I'm I'm storing a k8 secret, packed demo service, url, key and value, and the intent here is that when autodevops runs, it's automatically going to provision that environment inside of my review app or all subsequent applications as well. So you can see this by by default.

A

This is the autodevops pipeline, so I have a kubernetes cluster wired up to gitlab. So it's going to build it's going to do all this testing, it's going to deploy a review application and if I click on this, you can actually see that it's being deployed out to this review forward, slash verifying service registry, which is the branch name, um and this is what it looks like, and you can see that this packed demo service url is the same.

A

It's you know this url that's manually defined from the ci cd variable, which is nice, but sometimes you know again back to our use case. It would be nice to be able to dynamically support ephemeral environments, so I had this idea of what, if we had this service registry uh repository, that kind of was a source of truth. So let's pretend that we had this registry yaml file and this registry ammo file was had an index of all the projects.

A

So you can see that there's project one there's this django, auto devops project which I was referring to and this project has some dependencies, so it needs demo, sys users, tpoff, embarker, microservices, demo, packed demo impact provider, and maybe even this bogus app and anytime that a another app relies on these applications.

A

It should be stored as an environment, variable called django autodevops service url. So that way, there's consistency across all applications to make sure that the environment variable is always the same, and this this particular django, auto devops application, has been deployed into two locations, so this auto devops location for production and then this review environment has also been deployed and there's two other applications.

A

We have this packed demo and this pac demo is always going to be pac demo, service, url and there's production, environment and a review environment, and you can actually see that there's this review, verifying service registry and a staging environment. So ideally this enviro, this verifying service registry environment, would be utilized for the dependent to fulfill the dependency between the django, auto devops and pact demo, whereas the packed provider application has no um has no review environment, so we would always just rely on the staging environment instead.

A

So and down here. We we see that there is. There is a defined strategy, so the first order of precedence would be the ci environment, name, meaning that if the the environment names, this is an environment variable provided by gitlab. If this environment variable these match, it would go ahead and utilize that url, if it's been deployed out, otherwise we're going to rely on staging and if staging isn't available, we'll rely on production.

A

And what this looks like.

A

One other so uh yeah I'll go back to that, but what this looks like, rather than having this template- autodev ops yaml in my django autodevops project, I'm going to enable this project demo sys users, microservices service registry and rely on the autodevops file there and that file.

A

Is um fairly simple, it's it's, including the autodevops template, and then it's also adding a little bit of logic before the script and what's going to happen, is this: this logic is going to utilize this service registry and determine it's it's you're using really two primary commands or it's using bash logic as well as jq, which is provided by default in our auto, deploy image to parse out and determine which urls to utilize.

A

So I'm going to go ahead, and this is my pipeline and I'm going to go ahead and redeploy this application.

A

Additionally, one other thing that I did want to call out is within the service registry: template. That's that's being used.

A

I have I'm overriding. The auto devops das environment deploy job the review, job, the stop review job and I'm also including this register review job and the intent behind this register review job is to to call out to this service registry project and deploy and add to the yaml file.

A

So what it's going to do is it's going to kick off a ci job and the ci job is going to be picked up by the service registry project and what it's going to do is it's going to write to this code repository and it's doing that via a private token, and you could also use a project access token, which is going to be made available in 13.4 in gitlab.com and should be available in 13.3.

A

I believe so this this upcoming release, and so the project token or the private token or personal access token, are then being used. And, let's see if this review app has been deployed. So hypothetically, if I were to go back out here, I would see.

A

There's two service urls now available and you can see that this packed demo service url is pointing to a review app with the same branch and then the provider service. Url is this staging demo, which is again because it didn't have a review app associated with it?

A

Additionally, let's see if this automatically kicked.

A

Off we're back in the service registry project and I'm going to register the service.

A

By default, this will run upon completion of this review job, but since I replayed it, it doesn't seem like it picked it up.

A

A

And again, what's happening behind the scenes here is the.

A

uh Or simply, this autodevops file is going to utilize the environment variables from the project and pass those into the service registry project, and that logic is then going to be parsed by python, and then it's going to update the the service registry yaml file.

A

So that way so now we can actually see that there is a new entry into this service registry aml file. So now any subsequent environment that relies on the django autodevops project can utilize this environment url. If the the branch names.

A

Match some improvements, so uh you know you could always uh additionally so right now, this this logic is dependent upon um a few things. So we have these two need statements, one it needs to build before it happens uh and additionally, it's also relying on the um the register service job to generate an artifact on the master branch and then that artifact is what is being used. uh There's a json file, that's being parsed within this logic, that's then generating k8 secrets variables.

A

uh You could also utilize a gitlab pages page to host a json file. That is then parsed. I I don't know the best solution there. You could also tie this with a deprovisioning of an environment so upon deep provisioning of the environment. It automatically gets removed from the service registry, and then you could also provide consumers the ability to state what they need rather than requiring management of what they need in the service registry project.

A

Additionally, you can even use the you could pass the json web token over as a variable to verify that the consumer is who they say they are so that way they don't have the ability to modify somebody else's service registry entry. That's it for me thanks for your time.