CloudSnorkel
Option to support `Network Mode` in EC2 Task definition
@kichik I was looking into the constructs hub for the library and for my use case I would require to use Network Mode https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_ecs.NetworkMode.html from the Ec2Taskdefinition inside aws_ecs.
Just wanted to ask if it is currently in works ?
this.task = new ecs.Ec2TaskDefinition(this, 'task'); this.container = this.task.addContainer( 'runner', { image: ecs.AssetImage.fromEcrRepository(image.imageRepository, image.imageTag), cpu: props?.cpu ?? 1024, memoryLimitMiB: props?.memoryLimitMiB ?? (props?.memoryReservationMiB ? undefined : 3500), memoryReservationMiB: props?.memoryReservationMiB, logging: ecs.AwsLogDriver.awsLogs({ logGroup: this.logGroup, streamPrefix: 'runner', }), command: ecsRunCommand(this.image.os, this.dind), user: image.os.is(Os.WINDOWS) ? undefined : 'runner', privileged: this.dind, }, );
This could theoretically work. You can test by overriding the task configuration with something like:
const provider = new EcsRunnerProvider(...);
const taskDefinitionResource = provider.node.findChild('task').node.defaultChild as ecs.CfnTaskDefinition;
taskDefinitionResource.addPropertyOverride('NetworkMode', 'awsvpc');
taskDefinitionResource.addPropertyOverride('ContainerDefinitions.0.Environment', [{ Name: 'AWS_REGION', Value: cdk.Stack.of(provider).region }]);
It won't update the state machine to pass NetworkConfiguration, so that may cause it to fail. If that happens, you may have to edit the state machine to send that configuration with the subnet and security group for the task as well.
If that works, we can consider adding the option so it doesn't require overrides. I am curious though what you're expecting from this. Why is VPC mode per task needed? I seem to recall it severely impacts the number of containers that can run on every host. And in this case, all the containers will be using the same security group anyway, so you don't get the benefit of assigning different groups to different containers.
My primary goal is to be able to run integration tests on the self hosted runner in CI using GitHub actions and to achieve that I am trying to use Ec2 GitHub runners where I can let it listen to a particular port on which the web hook will be coming to from inside the VPC. The reason we need a VPC mode per task is that we need to receive web hooks for the E2E integration tests for every run or task hence we will need VPC mode per task.
The EC2 provider should work fine for your use case, yeah.
As for ECS, let's see if it can work first. Would you be able to test with the overrides above? Will the ENI limitations not break your use case?
Let me test it with the overrides above. I just need to share the Ip addresses of the instances where the test is running inside the CI stack that should work with ENI I believe.
Not sure what exactly you mean. A new EC2 instance will be created for each job.
If you're talking about GitHub's Runner Group feature, it's not supported yet on any provider. See #500.