#refarch (2023-07)
Cloud Posse Reference Architecture
2023-07-01
![Abra avatar](https://secure.gravatar.com/avatar/ec48c506ad3b9965c8052f4a3a1458cb.jpg?s=72&d=https%3A%2F%2Fa.slack-edge.com%2Fdf10d%2Fimg%2Favatars%2Fava_0009-72.png)
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](https://avatars.slack-edge.com/2020-04-14/1062347993890_6fd142c15ffef426eeba_72.png)
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](https://avatars.slack-edge.com/2020-04-14/1062347993890_6fd142c15ffef426eeba_72.png)
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](https://avatars.slack-edge.com/2020-04-14/1062347993890_6fd142c15ffef426eeba_72.png)
at this time i see it is not starting the desired instance. it is just spinning on github waiting for a runner
![johncblandii avatar](https://avatars.slack-edge.com/2020-04-14/1062347993890_6fd142c15ffef426eeba_72.png)
along these lines, could we have a separate group with min_size: 0
that is only used on demand?
![johncblandii avatar](https://avatars.slack-edge.com/2020-04-14/1062347993890_6fd142c15ffef426eeba_72.png)
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](https://avatars.slack-edge.com/2020-04-14/1062347993890_6fd142c15ffef426eeba_72.png)
any thoughts @Dan Miller (Cloud Posse)?
![Dan Miller (Cloud Posse) avatar](https://avatars.slack-edge.com/2021-08-12/2389147782305_5729c9d69c393852d209_72.jpg)
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](https://avatars.slack-edge.com/2021-08-12/2389147782305_5729c9d69c393852d209_72.jpg)
with eks/arc
you can have a runner type that can dynamically launch like this
![johncblandii avatar](https://avatars.slack-edge.com/2020-04-14/1062347993890_6fd142c15ffef426eeba_72.png)
thought so
![Dan Miller (Cloud Posse) avatar](https://avatars.slack-edge.com/2021-08-12/2389147782305_5729c9d69c393852d209_72.jpg)
whereas with github-runners
, you may need to simply deploy an additional ASG for your optional runner type
![johncblandii avatar](https://avatars.slack-edge.com/2020-04-14/1062347993890_6fd142c15ffef426eeba_72.png)
but with that we’d have to keep 1 instance always around, right?
![johncblandii avatar](https://avatars.slack-edge.com/2020-04-14/1062347993890_6fd142c15ffef426eeba_72.png)
or if we say 0, it would trigger the creation of 1?
![Dan Miller (Cloud Posse) avatar](https://avatars.slack-edge.com/2021-08-12/2389147782305_5729c9d69c393852d209_72.jpg)
yes I believe the min is 1
![johncblandii avatar](https://avatars.slack-edge.com/2020-04-14/1062347993890_6fd142c15ffef426eeba_72.png)
random thought, what about a GH step that triggers the creation of the desired instance?
![johncblandii avatar](https://avatars.slack-edge.com/2020-04-14/1062347993890_6fd142c15ffef426eeba_72.png)
hacky, but would save costs
![Dan Miller (Cloud Posse) avatar](https://avatars.slack-edge.com/2021-08-12/2389147782305_5729c9d69c393852d209_72.jpg)
that could probably work too, but it would take a bit for the runner to initialize of course
![johncblandii avatar](https://avatars.slack-edge.com/2020-04-14/1062347993890_6fd142c15ffef426eeba_72.png)
right. initialize 1 (maybe), start new one, it initializes, then things run
![Dan Miller (Cloud Posse) avatar](https://avatars.slack-edge.com/2021-08-12/2389147782305_5729c9d69c393852d209_72.jpg)
yup
![Erik Osterman (Cloud Posse) avatar](https://secure.gravatar.com/avatar/88c480d4f73b813904e00a5695a454cb.jpg?s=72&d=https%3A%2F%2Fa.slack-edge.com%2Fdf10d%2Fimg%2Favatars%2Fava_0023-72.png)
Also, without moving to Kubernetes, you may want to consider https://github.com/philips-labs/terraform-aws-github-runner
Terraform module for scalable GitHub action runners on AWS
![Erik Osterman (Cloud Posse) avatar](https://secure.gravatar.com/avatar/88c480d4f73b813904e00a5695a454cb.jpg?s=72&d=https%3A%2F%2Fa.slack-edge.com%2Fdf10d%2Fimg%2Favatars%2Fava_0023-72.png)
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.