GitLab Package Group, 14 Dec 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Dependency Proxy new features in GitLab 13.7

Description

This video covers new features being added to the Dependency Proxy in GitLab 13.7:

- DockerHub rate limit mitigation and offline support
- Support for private groups
- Authentication to protect your group's storage limits
- New predefined environment variables

A

Hey everyone: my name is steve abrams, I'm a back end engineer on the package team at get lab and I'm going to talk a little bit about the dependency proxy today, in version 13.7 we're going to be adding some really exciting features that I'm going to go over.

A

So let me go ahead and get started by sharing my screen here. um Let's see all right, so let me bump up my size. So if you're new to the dependency proxy, um we have some great documentation.

A

uh We can just head over to the get lab docs and then it's under packages and registries, and we can look at the dependency proxy and this can all be searched for as well by just dependency proxy.

A

If you haven't used the dependency proxy before it's great tool that allows you to pull images from docker hub and store them within your git lab infrastructure. So that way, next time you pull them again.

A

You won't need to reach out to docker hub they're just cached locally essentially, and this is helpful for speeding up pipelines like you can imagine if you have a pipeline that runs every few minutes or every time someone pushes code that pulls the node image that can sometimes take a while and then also with docker, recently rolling out rate limits on their polls from docker hub.

A

The dependency proxy will help you mitigate those um those rate limits, and so um I believe they rolled these out in november of 2020 and so just to take a look at docker's documentation. They give some tools to uh that. Allow you to take a look at what um how many different requests you've made. So I've copied those over, and so, if we run each of those first, we run a command to fetch a token and then the second.

A

We use that token to make a head request on what is essentially just a a dummy image, which is this repository rate limit preview image, and so you can see here. You've got a rate limit limit and a rate limit remaining, and so the limit is 100 pulls over 21 600 seconds, which is six hours, and you can see for me on my personal computer here. I have 99 remaining, so I'm still in a good spot.

A

But if I do something like docker pull alpine latest.

A

When I check that rate limit again, which I have a nice little alias for, you can see, we've moved down to 98.

A

so with every single pull you make of any image, um you're going to be penalized for that, and so how that works is when you make a poll for an image, there's two different types of files that are requested. First, you request a manifest which is kind of like a table of contents, or you know an index for the image itself. It says like what is this index made of and then using that manifest?

A

You request a series of layers, so docker has allowed everyone to make head requests for the manifest, and um you can see here they say doc or head requests are not counted, and so the head request, as you can see, one, it returns the rate limits, but it also for a given um image will return a digest value, and so this digest value is unique for that image. So we can determine okay when we request the manifest. Is our image the up to date, one or not, um and so with the dependency proxy.

A

If the image is out of date, the hash or the digest does not match, then we can pull from docker hub, but if it does match, we can just use what we have inside of the dependency proxy and our rate limit is not penalized.

A

It's also helpful. Let's say docker hub went down for a new reason.

A

You can use the dependency proxy then to make a request, and if you have the image already cached, then this header request for an image would fail, but the dependency proxy will just find your pre-cached image anyways and return it.

A

So, let's take a look at how that looks. So I have my local setup working, and so, if I were to do something like um a docker poll on this is just my local host here. Gdk.Test.

A

And so we have this dependency proxy url, which I'll show you in just a few minutes here um and so what you end up doing. Is you pull it through your specific url.

A

So if I pull through my local host, but I'm still pulling the alpine latest image.

A

We can see that my rate limit goes down one, because that first request is caching it inside of the dependency proxy. So it did make a request to dockerhub. But if I make that same request.

A

Again, that's a little confusing um somehow I must have reset over a period of time. uh Let's just try that one more time oh strange and try pulling one more time make sure that we have the right numbers all right great, so you can see that it did not change um because we're pulling directly from the cash not sure why we received 100 on that one request. But so I do have a little trick to show. Well what happens?

A

Let's say: I'm using the latest tag on an image, so the latest tag might change over time, meaning that the image will need to be updated whenever the latest tag is updated. So um I can sort of simulate that locally. Just so, you can see what it looks like here. I have a psql.

A

Interface open with my local database, and so we could see if I look at the manifests that I have in my cache- and this is not something you would ever need to do. This is purely just to kind of give a glimpse of what's going on here, you can see I've saved. Let me make this a little bit. Bigger I've saved the here see if we can actually pull this out.

A

I've saved the hash, that's returned or the digest. That's returned from the head request, and so, if I were to change it, so if I were to change that hash, so we're saying that the one I have is actually just a digest that equates to foo. When I pull again.

A

We're going to actually make a request to dockerhub and we'll see that my manifest then updates to the newest version, and so then that would penalize me as another request in terms of my rate limit, so that's kind of how the rate limiting works and is handled by the dependency proxy.

A

um The really nice thing, as I mentioned before, is that like, while I'm demoing this to you and going through these motions, you don't actually have to change how you use the dependency proxy at all in order to take advantage of this, if you're using the dependency proxy, this is now just built in it will help you mitigate that docker rate limit.

A

Another thing I want to talk about is an update we made in 13.7 to support private groups. So previously, if you wanted to use the dependency proxy, you had to use a public group, and there are a variety of reasons for this, but now we support private groups and in order to support private groups, you just have to authenticate against the dependency proxy and when I say authenticate, I just mean docker login.

A

So normally you would have a docker login or whatever server you're, using so for the dependency proxy. Since the proxy is git lab, you would use your git lab url or, if you're using gitlab.com it would be gitlab.com.

A

I think I'm actually logged into gitlab.com right now. So I'll log out.

A

And let's go ahead and pretend like we're going to set up a project here using ci and the dependency proxy, and just so we have this available, we'll open up the docs um there's an entire section on authenticating with a dependency proxy, and you can see here we're going to either use a docker login, which we can do straight through your ci scripts or if you want to be able to use, for example, the images that are specified sort of at the top level of your scripts, um the base level images, then you can add an environmental or sorry an environment variable to hold your credentials to log in.

A

So if we are setting up the dependency proxy, I have a private group here and over in the packages and registries tab. We can take a look at the dependency proxy, and here is that url that we kind of saw before when I was working locally.

A

This is the url that you're going to pull images through for any project within that group. So we can copy that, and you can see here- I've already pulled in 21 blobs of images which is equating to 700 megabytes, roughly and so from here. uh What I'd like to do is, let's see what happens if I try to pull an image through?

A

Let's just try that alpine image again, since it's a light, one that will go quickly.

A

So I'm receiving a 403 error, so I need to log in so. If I go ahead and log in to gitlab.com it'll, ask me for a username and password. This can be your username and password. It can be a personal access token. A variety of credentials will work here. So I'm going to go ahead and use a personal access token, um which I have somewhere around here.

A

Okay and now, if I go ahead and try to pull that same image there, we go when we have a poll. um So let's see how this works with ci, so in ci.

A

Let's create a ci file for this project.

A

We have this example here showing how you might log in within the actual script and depending on the complexity or what you're trying to do with your script. Maybe this works for you if you're logging into multiple registries, but maybe it doesn't, if you just want to be able to do something simple like let's say we wanted to do image.

A

Node latest, and actually I'm just going to keep it as alpine latest. So when we run this, it's it's fairly, quick in the demo.

A

Let's say we have a deploy stage.

A

A

In that stage,.

A

We have a script and in the script we'll just say it works, because we just want to make sure that we're pulling this image to begin with from the dependency proxy. So right now, if I were to commit this and run a pipeline, it's going to pull this from docker hub. So in order to pull it from the dependency proxy, we need the url prefix that our group gives us. So we need this prefix here.

A

Now we have a few um handy, uh predefined environment variables that you can use so for any project.

A

You can see, there's going to be a lot of copying and pasting of this group, so what we can do is looking at the docs here we have some environment variables for the user, the password this is kind of similar to when you use a job token to authenticate when you're running a job, and then we also have the server and the image prefix.

A

So you can see how those come into play here if I'm logging into a server, for example, I can log in with a user and password and then connect to a given server and then, when I'm pulling, I can use this notation here and use the group image prefix.

A

So let's use that one instead.

A

And so for that I just need to oops, add the prefix and then the last thing I need to do before this will work is um because I'm not logging in inside of this ci file.

A

I need to make use of the docker auth, config, environment variable, and so what you'll end up doing is taking whatever your credentials you're using um and you will come into a terminal and you'll base 64 the combination of them. So if my username is foo and my password is bar, then this is the value that I'm going to use, and so what I would end up doing is taking this block coming over to our project and going to the ci cd settings which I'll just open in the new tag tab here.

A

So we have environment variables.

A

You can see I've already added one in here since I don't want to actually show my credentials, but what you would end up doing is you'd end up pasting, that block that we have in the value and then this was docker off config and then we take our output from here and place it right in here and then make sure that you're using the right url.

A

So for us it would be gitlab.com but, like I said, I've already got that variable spelled out here and so now let's go ahead and commit this script and see whether or not we get a successful run. So, let's go to our ci pipelines.

A

You can see I've done a couple of these before on this project.

A

And it's already completed, but what we can take a look at here is that we're executing with this image that is pulled from gitlab.com.

A

It's from my group that url that we pulled for the dependency proxy and then the alpine latest image, so we're not pulling it from docker hub we're pulling it from the dependency proxy here and um now that it's within that dependency proxy cache anytime. We run this job in the future.

A

It will continue to use that cached image until um the latest tag is outdated, at which point it will pull the newest version of that image, and so you might wonder, okay well, let's say I'm using the node latest version and over the course of time, latest updates- and we have all of these old images stacked into our cache.

A

And um maybe this number is getting very high and we think maybe a lot of it is is just stale images that are no longer needed um well, for that we can go back to the docs and at the very bottom or towards the bottom. We have a clearing the dependency proxy cache, which is right now is currently supported through the api.

A

So what you'll need is an admin user from the group, so someone that has admin access within the group to run a delete request on this api url or in this api endpoint. So let's go ahead and try that out. I will.

A

Pull up a new tab here.

A

Oops and we'll paste this in.

A

All right, and so we just need to update a few of these values. First, we need to update the group id so to get that we just take a look at the group itself and there's the group id.

A

And make sure that we're using gitlab.com.

A

And then we will use your your personal access token or whatever types of credentials you're going to use, depending on the header that you'd like to use I've previously stored, my credential in an environment variable to make this a little easier and then I think we're all set, and so this is a successful request, no errors.

A

This is returning the id of a job. That's going to be performed so clearing the cache can be a heavy operation depending on how large the cache is. So it queues up as a background job and on gitlab.com, I'm guessing mine. It might not have even run yet. No, it's still still getting to it, um but you know you'll know that it's successful by doing that, and we only allow you to initially run this once per hour, because it is a heavy um job uh that could be.

A

You know you could be deleting multiple gigabytes of data here, so we want to make sure that it runs. If I, if I were to try to run it again, it'll it'll just throw back saying I have to wait an hour before I can run it again, but just know that it's running in the background, um I think that's it for the new features for the dependency proxy.

A

The other one note to mention is that in 13 points or 13 version, 13 6, the dependency proxy was moved to core, so it's available for all tiers to be able to use for free and then in 13.7. As I mentioned, we included the ability to mitigate that rate, limiting that docker hub introduced all right thanks for watching.