Pushing Image to AWS

[00:00:00]
>> Erik Reinert: Now, what we want to do is we want to update our pipeline so that it also takes care of the push step. So what I'm gonna do is I'm going to simply add a new step. What's neat about GitHub Actions, at least is you don't have to provide the environment variables to the entire job if you don't want to.

[00:00:25]
For example, if you're just like, I just want this one command to have access to the cli, you could totally do that. That's absolutely fine. That's exactly what we're doing. In this case, what we're doing is we're basically just saying, hey, for this specific run command or this specific step, add the environment variables to it.

[00:00:49]
Again, you guys can copy this from my repo. So I'm just going to go ahead and add it to my repo. Then I'm going to commit this and push it up. So I'm gonna do this, paste this in. So I'm noticing somebody in chat is also saying a nice alternative is to use OpenID Connect with your GitHub flows to authenticate with Amazon services.

[00:01:10]
Yeah, I fully agree. I actually do use that normally, but that's like an optimization on this. But the idea is that you can basically tell your Amazon account that GitHub can connect to your services as a unit or as an entity, right? And then you don't need to really give it credentials, it just identifies the pipelines that you're running and then will give you those credentials for it.

[00:01:38]
So it's kind of like Amazon identifies your repos and then recognizes when a repo goes to push something or build something, and then it goes, okay, well, I know that you're doing this. Here's a key for you. So it's the inverse. Instead of you creating keys and then putting them in there as secrets, you can kind of get them on the fly when you're running the pipelines.

[00:01:59]
Really quick shout out. We have a article on our blog about this too. So if you're curious about this, if you go to altf4blog and then click on using iam the secure way in GitHub actions, this will show you entirely how to set that up. This means that you don't have to create credentials and all that stuff.

[00:02:22]
You can just generate them on the fly in the actual pipeline. Cool, so again, for now we've got this and I'm going to go ahead and push this code up. Now, when I push this code up, I should expect to see two things happen. The first thing I should expect to see happen is I should expect to see that build step.

[00:02:45]
Then the second thing I should see is I should see it actually push that image to Amazon ECR and we should be able to confirm that that happened. Let's go ahead and let this build and push.
>> Student: Ubuntu already has Docker nowadays.
>> Erik Reinert: Yep, well, the GitHub Runner images do, yeah.

[00:03:10]
So the GitHub Runner images, you might be like, why aren't you installing Docker or any of the tools that you're running? So, as I said before, if you make your tools portable, you don't have to worry about that. How did we make our tools portable? We made Docker the primary tool because the runners have Docker on them at least.

[00:03:34]
I don't really need to install anything else because I'm running Docker to do everything and everything I need to do. So that's a little bit of a quick tip for anyone who ends up making pipelines in the future, or you're trying to figure out how to avoid installing so many things in the beginning of your pipeline.

[00:03:49]
Make a container image out of it, push that container image up, and then use that as your runtime with Docker. And like I said, we do that where I work, and it works really well. Okay, cool. So our build is just about done. Let's see if we get a push.

[00:04:10]
>> Student: Does this cost money?
>> Erik Reinert: Does GitHub Actions cost money? They have free. Whoops. Okay, so what happened? Tag does not exist. I need to make a small change to the Docker file. This was expecting it to be in a different state. I see. So it did run.

[00:04:37]
What's actually kind of nice is you can see here in the output, we did actually get our credentials and log in. And then when we went to push it, you'll see that it says refers to tag. Tag does not exist. The reason for that is because if we go to our makefile, you'll notice that we build with the git Shaw build image, riht.

[00:05:03]
But then down here, we push with the build tag, which is latest. That means that underneath the hood, if I do Docker image ls see how now I have a tag with like a really long value here. That's the git commit. This is a standard thing that I do at my company that I think is really worth doing, which is every time you build a Docker image in CI, use the commit of that image as the tag.

[00:05:35]
The reason for that is because one, it should always only build the same tag once because it's cached like that. But also it means that your devs, everyone in your company, all of your automation, everything uses the SHA as the version of that image, right? So if that's the version, then if you want to promote something, you would just say, okay, I want to tag off of that version to this tag.

[00:06:04]
And so what we're doing underneath the hood, when we're promoting something, we're really just saying, okay, this shawl should now be latest. So we're gonna tag off of this SHA to latest and then we're gonna push that. That's really our promotion process. So there was a small change that I needed to make.

[00:06:22]
It's right here. If you run into this problem, just be aware of it. Build image, push. In the first stage, because we were using latest, it expected latest, we want this to push the sha. So the idea is we're only pushing shaws and then we're pulling down shaws and then tagging and then pushing up the tag, right?

[00:06:43]
So that was the one thing that needed to be changed.