In this tutorial, I will create simple and practical example of how to provision EC2 instance with Github Actions and Terraform. I will use workflow_dispatch type of workflow which is triggered manually by user, using Terraform Github action from HashiCorp.
In this tutorial, I will show how to:
-
Deploy self-hosted-runner to Kubernetes and connect it with your GitHub repo.
-
Redeploy Nginx server on your k8s cluster with every change in nginx/deployment.yaml, which pushed to Github repo.
"Every change in configuration of deployment.yaml on Github will be propagated to Nginx server."
In this tutorial, I will show how to:
-
Deploy Actions Runner Controller (ARC) to Kubernetes and connect it with your GitHub repo.
-
Scale automatically your self-hosted runners count up to the total number of pending jobs in queue.
"The main purpose of this guide is to describe the real use case: AWS EKS cluster which is not externally accessible, only using VPN or inside of VPC to which cluster is provisioned."
In this tutorial, I will show how to:
-
Run self-hosted runners with Github Actions on AWS spot instances.
-
Dynamically add/remove resources to your k8s cluster by Karpenter.
"This guide is continuation of previous tutorial, please make sure you read it and have cluster with installed ARC."
In this tutorial, I will show how to:
-
Trigger Github Actions Workflow using PR comments like ‘/format’ (ChatOps). I will use 'slash-command-dispatch' for this.
-
Format the python code with PEP8 as part of PR and re-commit it again.
In this tutorial, I will show how to:
- Use OpenID Connect within your Github workflows to authenticate with Amazon Web Services.
"The reason behind that is security: Avoid storing long living AWS credentials (access_key_id and secret_access_key) in Github as a secrets."
- Improve the security of ‘EC2 provisioning’ workflow I described in first guide.