#refarch (2023-07)

Cloud Posse Reference Architecture

2023-07-01

Abra avatar

I am using leapp for my aws profiles management, i want to SSM to instance with profile but i need to pass a document something like this: aws ssm start-session --target INSTANCE_ID --document-name AWS-StartPortForwardingSessionToRemoteHost --parameters=portNumber=443,localPortNumber=443,host=REMOTE_HOST anyway I can achieve this with leapp?

2023-07-19

johncblandii avatar
johncblandii

Is there a way to define an optional github runner that’s started on demand via a label like:

    runs-on:
      group: <name>
      labels: m6a.2xlarge
johncblandii avatar
johncblandii

for context, i know we can request a specific instance with a label.

the core question here is if the runner could intelligently start a specific instance type

johncblandii avatar
johncblandii

at this time i see it is not starting the desired instance. it is just spinning on github waiting for a runner

johncblandii avatar
johncblandii

along these lines, could we have a separate group with min_size: 0 that is only used on demand?

johncblandii avatar
johncblandii

my goal is to have an instance for automation tests (high memory) ready on request, but not always around to save money.

it seems we’d have to have a high capacity instance always around

johncblandii avatar
johncblandii

any thoughts @Dan Miller (Cloud Posse)?

Dan Miller (Cloud Posse) avatar
Dan Miller (Cloud Posse)

we have two different methods of creating self-hosted runners – github-runners and eks/actions-runner-controller. The github-runners component is just an ASG, so it’s not as intelligent, whereas the eks/actions-runner-controller is built on EKS so it has a lot more features

Dan Miller (Cloud Posse) avatar
Dan Miller (Cloud Posse)

with eks/arc you can have a runner type that can dynamically launch like this

johncblandii avatar
johncblandii

thought so

Dan Miller (Cloud Posse) avatar
Dan Miller (Cloud Posse)

whereas with github-runners, you may need to simply deploy an additional ASG for your optional runner type

johncblandii avatar
johncblandii

but with that we’d have to keep 1 instance always around, right?

johncblandii avatar
johncblandii

or if we say 0, it would trigger the creation of 1?

Dan Miller (Cloud Posse) avatar
Dan Miller (Cloud Posse)

yes I believe the min is 1

johncblandii avatar
johncblandii

random thought, what about a GH step that triggers the creation of the desired instance?

johncblandii avatar
johncblandii

hacky, but would save costs

Dan Miller (Cloud Posse) avatar
Dan Miller (Cloud Posse)

that could probably work too, but it would take a bit for the runner to initialize of course

johncblandii avatar
johncblandii

right. initialize 1 (maybe), start new one, it initializes, then things run

Dan Miller (Cloud Posse) avatar
Dan Miller (Cloud Posse)

yup

Erik Osterman (Cloud Posse) avatar
Erik Osterman (Cloud Posse)

Also, without moving to Kubernetes, you may want to consider https://github.com/philips-labs/terraform-aws-github-runner

philips-labs/terraform-aws-github-runner

Terraform module for scalable GitHub action runners on AWS

1
Erik Osterman (Cloud Posse) avatar
Erik Osterman (Cloud Posse)

We haven’t had a chance to invest in it, as the simple ASG approach seems to work for most. But on EKS, we do a lot of the things you want to do, as it’s natively supported by the official github actions runner controller.

1

2023-07-24

    keyboard_arrow_up