_> 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!

Photo by rivage on Unsplash

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)

Photo by Patrick Tomasso on Unsplash

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.

​ Level Up Coding – Medium

about Infinite Loop Digital

We support businesses by identifying requirements and helping clients integrate AI seamlessly into their operations.

Gartner
Gartner Digital Workplace Summit Generative Al

GenAI sessions:

  • 4 Use Cases for Generative AI and ChatGPT in the Digital Workplace
  • How the Power of Generative AI Will Transform Knowledge Management
  • The Perils and Promises of Microsoft 365 Copilot
  • How to Be the Generative AI Champion Your CIO and Organization Need
  • How to Shift Organizational Culture Today to Embrace Generative AI Tomorrow
  • Mitigate the Risks of Generative AI by Enhancing Your Information Governance
  • Cultivate Essential Skills for Collaborating With Artificial Intelligence
  • Ask the Expert: Microsoft 365 Copilot
  • Generative AI Across Digital Workplace Markets
10 – 11 June 2024

London, U.K.