To achieve this goal we have to follow these steps:

1. Configure EC2 instance
2. Configure Github Actions for Automation
3. Configure Docker Compose
4. Make the project visible through EC2
5. Test all the configurations done

Configure EC2 Instance

Deploy an EC2 Instance Wiki Page for EC2

Connect to the instance already created by SSH

ssh -i "mi-clave.pem" ec2-user@<Public IP of the Instance>

Install Docker to the Instance Created

sudo yum update -y
sudo amazon-linux-extras enable docker
sudo yum install -y docker
sudo service docker start
sudo usermod -a -G docker ec2-user

Verify that docker it's installed

docker --version

Clone the repository and build the image Once we are connected to the Instance in EC2 have to clone our code then build the docker image

docker build -t ERAS .

Execute the container Run the container with the Instance port to be used

docker run -d -p 80:3000 mi-api

Here we can see that the port 3000 it's the port of the container and the port 80 it's the open port of the Instace that it's open for it's access.

Configure the Security Group

1. Open the configuration panel of the instance in EC2
2. Edit the security group to allow the traffic through the port 80:
   • Protocol: TCP
   • Port: 80
   • Source 0.0.0.0/0 (This allows the access from everywhere)

Test the connection Access to the project through the public IP of the instance

http://<Public IP of the Instance>/

Configute Github Actions for Automation

To have Github Actions working we have to add a deploy.yml file in the repository, the deploy file has to look similar to this:

on:
  push:
    branches:
      - main

jobs:
  deploy:
    runs-on: ubuntu-latest

    steps:
    - name: Checkout repository
      uses: actions/checkout@v3

    - name: Set up SSH
      uses: webfactory/[email protected]
      with:
        ssh-private-key: ${{ secrets.EC2_SSH_KEY }}

    - name: Deploy to EC2
      run: |
        ssh -o StrictHostKeyChecking=no ec2-user@<IP_PUBLIC_EC2> << 'EOF'
        cd /ruta/a/tu/repositorio
        git pull origin main
        docker-compose down
        docker-compose up -d --build
        EOF

Important Details:

• secrets.EC2_SSH_KEY:
  • Add the SSH key as secret to the repository
    • Settings > Secrets and variables > Actions
    • Create New Repository Secret
    • Name the secret as EC2_SSH_KEY
• IP_PUBLIC_EC2
  • Replace this with the public IP of the Instance

Configure Docker Compose

In the project folder of the EC2 Instance create a docker-compose.yml file:

version: '3.8'
services:
  api:
    build:
      context: .
    ports:
      - "80:3000"
    restart: always

Test the Configuration Done

• Make a commit and push it to the main branch
• Github Actions will execute the workflow:
  • It will clone the updated repository
  • Will run git pull in EC2 to get the last changes
  • Will restart and build the docker containers

Aditional option to run github self-hosted runner in the EC2 instance:

The configuration needs to be downloaded configured and then run on the workflow file for each job as: runs-on: self-hosted These steps are explained here

Using GitHub Actions with SSH

• Pros: Simplicity: Setting up a GitHub Action to SSH into your EC2 instance is straightforward and requires minimal configuration. You can execute commands directly in your workflow without managing a persistent runner. Isolation: Each deployment can run in a clean environment, reducing the risk of state carryover between deployments. Less Maintenance: You don’t need to manage the self-hosted runner application or its dependencies.
• Cons: Latency: Each deployment involves SSH overhead, which can introduce latency compared to running jobs locally on the EC2 instance. Limited Control: You may have less control over the execution environment since you are relying on SSH commands rather than executing jobs

Directly through GitHub Actions.

Security Risks: Exposing SSH access can increase security risks if not managed properly. Using Self-Hosted Runners on EC2

• Pros:
  • Performance: Self-hosted runners can execute jobs faster since they run directly on the EC2 instance without the overhead of SSH.
  • Customization: You have full control over the environment, allowing you to install specific software and configure settings tailored to your application’s needs13.
  • Integration: Self-hosted runners can handle more complex workflows that require multiple steps or dependencies without needing to connect remotely each time.
• Cons:
  • Maintenance Overhead: You must manage the self-hosted runner, including updates and security patches. This requires additional effort and expertise24.
  • Cost Management: While self-hosted runners are free in terms of GitHub Actions usage, you still incur costs for running the EC2 instance continuously, which may not be cost-effective for smaller projects5.
  • Setup Complexity: Initial setup can be more complex as you need to configure the runner application and ensure it communicates properly with GitHub34.

Conclusion

The decision between using a GitHub Action with SSH or a self-hosted runner depends on your specific needs: For simplicity and minimal management, using GitHub Actions with SSH might be more convenient, especially for smaller projects or infrequent deployments. For performance and control, especially in larger projects with complex workflows, setting up a self-hosted runner on EC2 would be advantageous despite the additional maintenance required. Ultimately, considering our project's scale, frequency of deployments, team expertise, and security requirements I recommend using an SSH approach.