This content originally appeared on Level Up Coding - Medium and was authored by Aditya Chandhoke
_> AWS, Workflow Execution, Project Deployment
Welcome back guys, today we’re going to continue building on our last blog by deploying the project on AWS and seeing it in action.
Let’s get straight into it!
AWS Setup (Part 2)
If you followed the last blog you will be settled in a EC2 Instance Console. We will move forward from there. In the console we’ll run a few commands:
sudo apt-get update -y
sudo apt-get upgrade
curl -fsSL https://get.docker.com -o get-docker.sh
sudo sh get-docker.sh
sudo usermod -aG docker ubuntu
newgrp docker
These commands will update and upgrade the machine (package installation), then we use curl — This command downloads the Docker installation script and saves it locally as ‘get-docker.sh’, next we run the Docker installation script with root privileges to install Docker on your system. We have to add your user to the docker group so you can run Docker commands without needing sudo. Finally, this last command refreshes your group memberships so you can start using Docker without needing to log out and back in.
Just give docker a little check by calling the docker command to see if everything is working.
Now we’ll give a little rest to the EC2 machine and setup a runner for our repository. A GitHub Actions runner is a server that runs your GitHub Actions workflows. You can use GitHub’s hosted runners or set up your own self-hosted runners on your infrastructure. This gives you more control over the environment and resources used to run your workflows.
I wanna walk you through this but I won’t, as it is just copying pasting some commands and I want you to explore on your own as to what they do.
So go to the settings of your repository and in the left side column you’ll find Actions, under that click on Runners and click on the New self-hosted runner. On the new page choose Ubuntu and just copy past the command from below into your EC2 machine. That’s it!
(** During the config of GitHub actions on EC2 when it asks for the runner name not group, write “self-hosted”)
After you’ve done everything, when you run the last script the EC2 machine will start listening for jobs — i.e any changes we make to our repository will start a reaction from GitHub actions. What reaction you may ask?
That is the thing we’re setting up next! A GitHub workflow for our repository, but before that we need to set up a bunch of secret keys so that our workflow can access our EC2 machine and other stuff.
On the GitHub settings page, under the security section you’ll find the Secrets and Variable tab, click on Actions. Here we can create our keys.
Now here we have to make 5 new keys namely:
AWS_ACCESS_KEY_ID — This will be available in the csv file that we downloaded in the last blog!
AWS___SECRET_ACCESS_KEY — Again you will find this in the same csv file.
AWS_REGION — You can find this on the top left corner of your EC2 terminal page.
AWS_ECR_LOGIN_URI — In the last blog I asked you to save a URI in a text file while we were setting up the registry, that will be used here. This should just be the link without the ECR repository name.
ECR_REPOSITORY_NAME — The name of the ECR that you created. (If you’re having trouble you’ll find all this info on your AWS account, just search for specific stuff)
Now to see things in action, make any small random change to the code base see how the workflow execution happens!
(**Check GitHub actions for the CI/CD workflow)
Now we’re ready to view our project that is deployed on AWS. A last finishing touch that we will give is changing the inbound rules so as to view our project on our specified port number.
On your AWS account, open EC2 page and select your instance. If you scroll a little you will come across the security tab. In that click on the inbound rules and add a new rule :
Type — Custom TCP
Port Range — 8080
And that’s it!
On your homepage of your EC2 instance you’ll find your ‘Public IPV4 address’, open that and voila!
(**Remember to close down all the AWS systems after you’re finished, as you could incur charges)
This has been a fantastic journey for me, going through the process of building a production ready application that can be maintained and scaled for future purposes. The amount of mistakes I made were pretty substantial but every fall proved to be a learning journey in itself. If you reached this point — Congratulation! Hope you’re enjoying whatever you’ve built! Do share it with me if you’d like to!
See ya next time! Happy Coding!
End to End Machine Learning Project Part-8(2) was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.
This content originally appeared on Level Up Coding - Medium and was authored by Aditya Chandhoke
Aditya Chandhoke | Sciencx (2024-06-27T13:06:42+00:00) End to End Machine Learning Project Part-8(2). Retrieved from https://www.scien.cx/2024/06/27/end-to-end-machine-learning-project-part-82/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.