Question/Feature Request: Full configuration as code about amazon-ecs-plugin

[pbsladek]

@gomesp I use this plugin everyday via jcasc. Happy to help out on any specific issues you are having. Here is one of the slave configs i use. Haven't tried the lastest, but def works fine with configuration-as-code:1.19 and has for months.

  clouds:
    - ecs: # 4cpu-8gb
        cluster: "arn:aws:ecs:${AWS_REGION}:${AWS_ACCOUNT_ID}:cluster/xxxxxx-${AWS_JENKINS_ENVIRONMENT}-jenkins-ecs-cluster"
        credentialsId: "xxxxxxx_jenkins_xxxxx_credentials"
        jenkinsUrl: ${JENKINS_HOST_URL}
        name: amz2-4cpu-8gb
        regionName: ${AWS_REGION}
        retentionTimeout: 60
        tunnel: "${JENKINS_TUNNEL_URL}:${JENKINS_SLAVE_PORT}"
        templates:
          - assignPublicIp: false
            cpu: 4096
            image: xxxxx/xxxxxxxxxxx
            label: amz2-4cpu-8gb
            launchType: EC2
            memory: 8192
            memoryReservation: 4096
            networkMode: default
            privileged: false
            remoteFSRoot: /home/jenkins
            templateName: amz2-4cpu-8gb

[markjacksonfishing]

I am still debugging

[webratz]

Also quite some of the delay comes from Jenkins weird internal mechanism on when to request agents.
This can be changed / optimized with some system params, eg -Dhudson.slaves.NodeProvisioner.initialDelay=0 -Dhudson.slaves.NodeProvisioner.MARGIN=50 -Dhudson.slaves.NodeProvisioner.MARGIN0=0.85

[gomesp]

Did you find a way to achieve this @gomesp ?

Not yet. But it seems that @markyjackson-taulia is picking it up, so this is great news.

Currently I use the EC2 plugin to spin up agents dynamically (which supports CasC), but I'm looking forward to move to ECS with this plugin in the future.

[keyotik]

Afaik this is not supported and i don't know if it even could be. This would be something I'm sure a eks kind of thing might be able to solve. We just bite the cold start times to be honest. It only adds about an extra 15-30 secs for us per build. 30secs isn't an issue for us on 5-10min builds. I haven't tested Fargate.. We use EC2.

Some ideas (shave time elsewhere):

• Implement a shared cache for things like a maven cache. Otherwise images have to re-download.
• Reduce your docker image size. alpine etc.
• ECS_IMAGE_PULL_BEHAVIOR aws-ecs-image-caching. I just found this.. might play with it and report back.
• Might be able to "warm" the tasks. Like a job that builds a few temp projects every min so that the slave for that image is quicker to spin up (no clue if this is even a thing..just an idea that you could test and probably overcomplicates things).

How long are your builds?

Thanks @pbsladek for the reply. The whole build time takes around 15mins (including tests and deployments). Thanks for the ideas, I'll add this in our documentation. I have brought it up with our team and our current implementation of having the Jenkins agents on EC2 instances using the EC2 plugin is working as expected and no issues have been reported so we might stick with it for now. Again, thanks a lot for the support!

[ChristopheBougere]

Did you find a way to achieve this @gomesp ?

[ChristopheBougere]

Good news is there anywhere we can track progress @markyjackson-taulia ?
I was planning to use Fargate, so I'd like to start directly using this plugin :/

[gomesp]

Awesome @pbsladek, I'll give your example a try!

[pbsladek]

@gomesp Any luck?

[gomesp]

Oh, my apologies @pbsladek. I've delegated this to @keyotik. Tagging him here for his feedback.

[keyotik]

Hi @pbsladek , sorry for the delayed reply. Before moving to the casc, I wanted to try if I can stand up the Jenkins agents on ECS. But I do have a question first, is it possible to provision the agents on ECS (EC2 or Fargate) as a "stand-by" pool? Meaning we want the agents to be up and running for the whole day and ready to accept jobs instead of provisioning them on the fly everytime?

Our use case for this is that our development team want's to improve the build/deploy time and if provisioning of the agents is added to it everytime, this will definitely impact them reaching their build pipeline time goal.

[pbsladek]

Afaik this is not supported and i don't know if it even could be. This would be something I'm sure a eks kind of thing might be able to solve. We just bite the cold start times to be honest. It only adds about an extra 15-30 secs for us per build. 30secs isn't an issue for us on 5-10min builds. I haven't tested Fargate.. We use EC2.

Some ideas (shave time elsewhere):

• Implement a shared cache for things like a maven cache. Otherwise images have to re-download.
• Reduce your docker image size. alpine etc.
• ECS_IMAGE_PULL_BEHAVIOR aws-ecs-image-caching. I just found this.. might play with it and report back.
• Might be able to "warm" the tasks. Like a job that builds a few temp projects every min so that the slave for that image is quicker to spin up (no clue if this is even a thing..just an idea that you could test and probably overcomplicates things).

How long are your builds?

[pbsladek]

@webratz thx! Will def give those a go and report back 😄

[pbsladek]

@webratz Very noticeable improvement. Maybe 5 secs max now. Thx again.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[jaekunchoi]

is it possible to use EC2 instance profile instead of credentialsId in the cloud config ?

[bradq]

@hybmg57 the value should be nullable. Not providing credentials at all invokes the standard AWS preference chain for authentication.