For an alternative proposal that uses simple CloudFormation YAML patches, see #4209!

I really love this! The only addition I'd have is to take it even further. A lot of the power of the CDK is high level abstractions, so it'd be nice to have a Copilot abstraction that takes care of details like knowing where/how to template include and possibly having opinionated/type-safe ways of getting templated resources.

Hi @RichiCoder1 👋

Thanks for the feedback! Are you thinking of something along these lines:

import * as copilot from 'aws-copilot-lib';

const props = copilot.buildPropsFromManifest('../manifest.yml');
const lbws = new copilot.LoadBalancedWebService(this, 'Web', props);
const service = lbws.getService(); // returns L2 ECS service construct.                  

One benefit that I can think of with this route is that it would allow you to compose CDK apps made out of Copilot abstractions 👍.
Or were you thinking of a different option?

that takes care of details like knowing where/how to template include

For clarification, when running copilot svc/env override, Copilot will scaffold the following piece of code:

constructor (scope: cdk.App, id: string, props?: cdk.StackProps) {
      super(scope, id, props);
       this.template = new cdk.cloudformation_include.CfnInclude(this, 'Template', {
          templateFile: path.join('.build', 'in.yaml'), 
      });

And everytime copilot svc package or copilot deploy is run Copilot will write the CloudFormation template automatically under .build/in.yaml so no user action is needed.

opinionated/type-safe ways of getting templated resources

Similarly, Copilot will scaffold the following line:

const service = this.template.getResource("Service") as ecs.CfnService;

The service variable is now a type-safe L1 CDK construct: https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_ecs.CfnService.html

Do these responses mitigate your concerns?

I think this is great! I have a few questions/comments:

• Will there be a beta we can use before the final release of this feature (if it is released)?
• Currently, any generated cloudformation from copilot isn't visible until its actually deployed to AWS. Would there be a synth-like command that could be run from copilot to show us everything that will be deployed (not just the CDK we've written to override/expand services/jobs etc.)
• I think having constructs that represents the abstracted "service" or "job" etc would be very helpful. That way we can work with a single construct as opposed to working individually with each resource that composes the abstraction/pattern. See: https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_ecs_patterns-readme.html ... I'm not sure of the patterns here track with what copilot releases.

Hello @benjaminpottier!

I can probably answer your second question - inviting @efekarakus for the other two!

Currently, any generated cloudformation from copilot isn't visible until its actually deployed to AWS. Would there be a synth-like command that could be run from copilot to show us everything that will be deployed (not just the CDK we've written to override/expand services/jobs etc.)

You should be able to run copilot svc package to preview the CFN template that would be generated after applying the CDK code changes. In addition, we are thinking about adding --diff flag to copilot svc package for folks to view the difference between the deployed template and the local template. Would these be helpful for you?

Hello @benjaminpottier!

I can probably answer your second question - inviting @efekarakus for the other two!

Currently, any generated cloudformation from copilot isn't visible until its actually deployed to AWS. Would there be a synth-like command that could be run from copilot to show us everything that will be deployed (not just the CDK we've written to override/expand services/jobs etc.)

You should be able to run copilot svc package to preview the CFN template that would be generated after applying the CDK code changes. In addition, we are thinking about adding --diff flag to copilot svc package for folks to view the difference between the deployed template and the local template. Would these be helpful for you?

That answers my question. Thank you! And yes, diff would be helpful.

We are currently planning to use copilot in "compliance environments" (UK Public Sector), where individual development teams have limited access to AWS APIs (i.e. no ability to apply CF from local terminal).

What this looks like is using Copilot strategically as a tool as part of a larger "platform offering" from a centralised platform team. I do wonder how these advanced override features will evolve over time and be suitable in those scenarios.

My current view is that there would either need to be an abstraction around copilot, or some sort of copilot-managed concept that groups "Applications" into a wider platform, and allows cross-cutting changes to be applied to many teams copilot managed services.

Hi @bpottier, @craigjbass !
Apologies on the late reply, I was at re:invent 😎

Will there be a beta we can use before the final release of this feature (if it is released)?

We can happily share a pre-release binary here before submission to get early feedback on the feature, that's a great idea 👍

I think having constructs that represents the abstracted "service" or "job" etc would be very helpful.

That's really interesting, we can definitely create a L3 construct that takes the same manifest file as an object as input. Similar to in this comment:

const lbws = new copilot.LoadBalancedWebService(this, 'Web', {
  http: {
     path: '/',
     targetPort: 80,
  },
  image: {
     build: './Dockerfile',
  },
});

Are you inclined for this abstraction so that you can have all your infrastructure defined in the CDK?

My current view is that there would either need to be an abstraction around copilot, or some sort of copilot-managed concept that groups "Applications" into a wider platform, and allows cross-cutting changes to be applied to many teams copilot managed services.

Interesting! Can I ask some clarification questions @craigjbass 🥺:

1. Do you deem it's okay if this feature is reserved to the platform team rather than the dev teams?
2. Out of curiosity: How will dev teams make changes to their services? Do they have access to the manifest.yml files and can do a git push to trigger the copilot pipeline to apply their changes?
   3.Is the concern applying the same "extension" across multiple manifest files? If so I think a pattern like this can be possible:

   import {customTransform} from '../../common/transform-copilot.ts'; // Import from a common path or a published node module.
   
   constructor (scope: cdk.App, id: string, props?: cdk.StackProps) {
      super(scope, id, props);
       this.template = new cdk.cloudformation_include.CfnInclude(this, 'Template', {
          templateFile: path.join('.build', 'in.yaml'), 
      });
      customTransform(this.template.getResource("Service");  // Apply the transformation here.
   }

1. Do you deem it's okay if this feature is reserved to the platform team rather than the dev teams?

Yes, although I wonder how we'd enforce that without simply not providing the Copilot CLI to teams. I can see a benefit in giving some but not all of the functionality of the Copilot CLI directly to dev teams. (Mostly around operability)

2. Out of curiosity: How will dev teams make changes to their services? Do they have access to the manifest.yml files and can do a git push to trigger the copilot pipeline to apply their changes?

Unclear yet. Ideally, they would just use the copilot manifest, but if we can't put in the relevant controls - they will probably commit a manifest that a custom tool will read to produce the copilot manifest. Examples of areas where this might be beneficial are for applying security groups without referencing a security group by ID.

3.Is the concern applying the same "extension" across multiple manifest files? If so I think a pattern like this can be possible:

Yes but also in restricting the scope of the contract between platform and dev teams.

I can see a benefit in giving some but not all of the functionality of the Copilot CLI directly to dev teams. (Mostly around operability)

That totally makes sense.
For operability, if we are talking about commands such as copilot svc show, copilot svc status, copilot svc logs then I think we can get away by assigning dev teams IAM roles that have only read actions allowed and these commands should work.

If we want dev teams to be able to modify infrastructure, but only limited to particular actions and resources, I think we need to put some more thought into it. 💭
Today, we allow IAM role boundaries to ensure certain actions are denied but to me it sounds like instead we need ways of customizing the CloudFormationExecutionRole to limit it only for devs. This way if the CFNExecRole is limited then devs having access to manifests and extensions won't matter

IAM Role boundaries look good - although it doesn't seem possible to apply that to an existing app?

In terms of bringing this back on topic to CDK extensions.

If we want dev teams to be able to modify infrastructure, but only limited to particular actions and resources, I think we need to put some more thought into it. thought_balloon

Looking at this as a "Platform in a Box" capability of Copilot, what would be ideal is if Copilot allowed a central platform team to define templated "bits of infrastructure" which can be turned on and off inside the manifest yaml with something as simple as a boolean flag. Cross-cutting definitions of infrastructure, rather than giving dev teams the keys to AWS itself.

IAM Role boundaries look good - although it doesn't seem possible to apply that to an existing app?

That is the case indeed today.

Looking at this as a "Platform in a Box" capability of Copilot, what would be ideal is if Copilot allowed a central platform team to define templated "bits of infrastructure" which can be turned on and off inside the manifest yaml

👍 We have plans in the future, using CDK extensions, for platform teams to define their own "Custom" manifests. Something like:

$ copilot svc init
Which service type best represents your service's architecture?
  > Load Balanced Web Service   (Internet to ECS on Fargate)
  > Backend Service             (ECS on Fargate)
  > Worker Service              (Events to SQS to ECS on Fargate)
  > Custom                      (Define your own using `copilot svc override`)

If I'm understanding correctly that seems to fit into the use case you're describing. Our plan is to allow platform engineers to register a custom type with Copilot which can then be used by dev teams. The devs would interact with the manifest file, and platform teams using the CDK would define the transformations from manifest to infrastructure.

Side note: have you explored AWS Proton? They're specializing specifically for this usecase. They provide some advanced functionality too for platform teams such as monitoring the version of the services that are deployed across environments. If you have any questions for them, you can post here.

Hey all! I just added a design proposal to add a --diff flag to deploy and package that should be helpful when working with extensions. Feel free to take a look and leave any feedback over there! #4259

Apologies for the very late reply, wanted to follow up!

One benefit that I can think of with this route is that it would allow you to compose CDK apps made out of Copilot abstractions 👍.

That would be interesting, but would also likely conflict with the pre-existing ECS Patterns and ECS Service Extensions. I could see still creating them as an eject option or slightly better maintained alternative however.

Similarly, Copilot will scaffold the following line:
const service = this.template.getResource("Service") as ecs.CfnService;
The service variable is now a type-safe L1 CDK construct: docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_ecs.CfnService.html

My thought process was that since Copilot (roughly) knows the shape of the template, instead of using raw keys and casting to the correct L1, copilot could expose an abstraction that surfaces these L1's as properties.

Something like:

constructor (scope: cdk.App, id: string, props?: cdk.StackProps) {
   super(scope, id, props);
   // This construct already knows where the template lives, but you can optionally override it.
   this.generated = new copilot.GeneratedTemplate(this, "Template" /*, { ... } */);
   // template.service is an L1 Service
   customTransform(this.genereted.service);
   // or to work with the raw bits
   this.generated.template
}

With that above stated I like the above ideas where while CDK handles the meat of the synth and deployment, Copilot still provides value via developer niceties like log tailing, debug assistance, etc...

Instead of using raw keys and casting to the correct L1, copilot could expose an abstraction that surfaces these L1's as properties.

That makes a lot of sense! It reminds me of how Amplify overrides work (example)

Here is what I'd love to see:

Thanks @PedroAlvarado for the awesome diagram 😍 ! I have a few questions if you don't mind 🙇

1. Can you expand a little bit on the L3 builder interface? Do you have a sample pseudo-code to illustrate the interface in mind?
2. Do you not feel like the proposed solution above help you achieve (1) enforcing requirements and (2) enabling customization and new resources?

Overrides for, say, LocalStack

This is really interesting, because it makes it sound like you would like to customize the CLI itself, say by changing the UI or commands, (like here) and not just the infrastructure.
3. Am I understanding correctly?

Hi folks!!

I'm really excited to say that AWS Copilot v1.27 is out and CDK extensions is now supported! 🚀

• Guide: https://aws.github.io/copilot-cli/docs/developing/overrides/cdk/
• Blog post: https://aws.github.io/copilot-cli/blogs/release-v127/
• Release notes: https://github.com/aws/copilot-cli/releases/tag/v1.27.0

I'll close the issue now! If you have any questions, feedback, or suggestions please feel free to open new GitHub issues 🥳