[ECR] [request]: native buildpack support
- Dominant language
- Shell
- Stars
- 5.4k
- Forks
- 334
- PR merge metrics
- No merged PRs in 30d
Description
### Community Note
* Please vote on this issue by adding a 👍 [reaction](https://blog.github.com/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/) to the original issue to help the community and maintainers prioritize this request
* Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
* If you are interested in working on this issue or have submitted a pull request, please leave a comment
**Tell us about your request**
I would like to have somewhere that I can submit a codebase and have it built with [Cloud Native Buildpacks](https://buildpacks.io/) without requiring a Dockerfile. App Runner has a similar feature in its "Build From Source" feature, but that seems to have a pretty limited set of runtimes (python and node currently). Full buildpack support would be much more flexible. Features listed on their website:
**Advanced Caching**
Robust caching is used to improve performance.
**Auto-detection**
Images can be built directly from application source without additional instructions.
**Bill-of-Materials**
Insights into the contents of the app image.
**Modular / Pluggable**
Multiple buildpacks can be used to create an app image.
**Multi-language**
Supports more than one programming language family.
**Multi-process**
Image can have multiple entrypoints for each operational mode.
**Minimal app image**
Image contains only what is necessary.
**Rebasing**
Instant updates of base images without re-building.
**Reproducibility**
Reproduces the same app image digest by re-running the build.
**Reusability**
Leverage production-ready buildpacks maintained by the community.
**Which service(s) is this request for?**
I could see this being a part of ECR, [EC2 Image Builder](https://aws.amazon.com/about-aws/whats-new/2020/12/ec2-image-builder-supports-container-images/) (although that name is already a bit misleading), or some net new service. I imagine this to be similar to the CI/CD piece of App Runner, but publishing the final docker image to ECR so that it can be used in EKS, ECS, Fargate, or any other system (Lambda?) which supports docker images as artifacts.
**Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?**
Dockerfiles usefully provide exact control over the final image that you're building, but they also come with drawbacks:
* Docker expertise needed: there are all sorts of blog posts, best practices for image optimization, and so on that can be overwhelming for developers to wrap their heads around
* Maintenance required to stay up to date: package upgrades, base image updates, etc. require applications to be modified and re-built in order to stay up to date
It would be nice to have an alternative which wouldn't even require a Dockerfile, simply connect a repository with application code and have it built and published to ECR. Buildpacks have an existing ecosystem of supported buildpacks ([paketo](https://paketo.io/docs/buildpacks/language-family-buildpacks/), [heroku](https://github.com/heroku?q=buildpack&type=&language=&sort=), etc)
**Are you currently working around this issue?**
We have to write Dockerfiles and configure build pipelines.
**Additional context**
* https://github.com/aws/apprunner-roadmap/issues/11
* [Google Cloud Buildpacks](https://cloud.google.com/blog/products/containers-kubernetes/google-cloud-now-supports-buildpacks)
* [Azure Buildpacks](https://docs.microsoft.com/en-us/azure/container-registry/container-registry-tasks-pack-build)
* https://www.youtube.com/watch?v=SK6e_ZatOaw

Contributor guide
Research direction
No repository files, tests, or entry points are identified. Start by reviewing the Cloud Native Buildpacks request and its proposed ECR or EC2 Image Builder placement, then compare the stated build, publish, and runtime goals with the roadmap scope. Done would require a decided service boundary and an implementation plan.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- aws, docker
- Domain
- cloud, devops
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 20/100