Buildpack support - Githubissues

purintai commented 3 years ago

Community Note

Please vote on this issue by adding a 👍 reaction 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

https://buildpacks.io/

It's best to support Buildpack rather than adding any runtime. Isn't it?

estheban commented 3 years ago

:+1:

Having the possibility to support buildpack or custom runtime will unblock a lot of supported language.

mwarkentin commented 3 years ago

Yeah, seems like the current runtimes still require you to define how to install requirements, etc: https://docs.aws.amazon.com/apprunner/latest/dg/service-source-code-python.html

ekcasey commented 3 years ago

👋 I work as maintainer on both the Cloud Native Buildpacks project and Paketo which provides buildpack implementations for a variety of runtimes including Java (https://github.com/aws/apprunner-roadmap/issues/16) and Golang (https://github.com/aws/apprunner-roadmap/issues/10). Happy to answer questions and provide support if y'all decide to go forward with buildpack support in App Runner.

mwarkentin commented 3 years ago

I opened https://github.com/aws/containers-roadmap/issues/1409 on the main container roadmap repo too.

hrnatha commented 2 years ago

Hello App Runner & Buildpacks community!

We here at AWS are super excited to see how passionate you are about Cloud Native Buildpacks, and we want to deliver the best experience possible for those of you who are already used to the simplicity and deep functionality Buildpacks offer.

On that note, we have a few questions I'd like to ask the Buildpacks community, to help shape this experience for you:

When a service launches "Buildpacks support," what does that mean to you? Do you find yourselves most frequently using curated Builder images (from a cloud provider and/or third-party), or are you more likely to create your own Builder images (and corresponding Buildpacks) to suit the needs of your specific application?
For those of you who leverage your own Builder images, where is your preferred storage location? Presuming it's an image repository, do you use DockerHub, ECR, an on-premises repo, or a different solution entirely?
Buildpacks enthusiasts, in your opinion, what is it about Buildpacks that makes it a difference maker for you? What is the core incentive to you in terms of undergoing the effort of maintaining your Buildpacks in addition to your application code? (e.g. "build as code" ease-of-use, flexibility to deploy Builders across projects, consistent build environments, etc.)

jared-christensen commented 2 years ago

I mostly use curated images because I’m newer to docker. We hit the docker hub request limit so we mostly use ECR. I like the images Amazon host, I just wish there were more. Ease of use is the most important to me. I need to learn more about buildpacks, this is my first time hearing about them. We are bitbucket users so right now we have a pipeline that watches our repo and on changes pushed a docker image to ECR that app runner is watching for changes.

RichiCoder1 commented 2 years ago

When a service launches "Buildpacks support," what does that mean to you?

In this case, something similar to how "Code-based service" works today, except with various curated and well-defined buildpack options for more languages.

Do you find yourselves most frequently using curated Builder images (from a cloud provider and/or third-party), or are you more likely to create your own Builder images (and corresponding Buildpacks) to suit the needs of your specific application?

Usually to start with curated, but with the ability to build upon them later to introduce extra-company specific opinions like tracing, instrumentation, or the like.

For those of you who leverage your own Builder images, where is your preferred storage location? Presuming it's an image repository, do you use DockerHub, ECR, an on-premises repo, or a different solution entirely?

DockerHub or GHCR currently, but no strong opinion. Ideally GHCR or ECR.

Buildpacks enthusiasts, in your opinion, what is it about Buildpacks that makes it a difference maker for you? What is the core incentive to you in terms of undergoing the effort of maintaining your Buildpacks in addition to your application code? (e.g. "build as code" ease-of-use, flexibility to deploy Builders across projects, consistent build environments, etc.)

In part, simplicity for developers while also baking in best practices and opinions without having to maintain multiple fragile Dockerfiles in multiple places. In theory, the ability to automatically rebase the image would be great too.

mwarkentin commented 2 years ago

When a service launches "Buildpacks support," what does that mean to you? Do you find yourselves most frequently using curated Builder images (from a cloud provider and/or third-party), or are you more likely to create your own Builder images (and corresponding Buildpacks) to suit the needs of your specific application?

Leverage curated images unless there's something custom we need.

For those of you who leverage your own Builder images, where is your preferred storage location? Presuming it's an image repository, do you use DockerHub, ECR, an on-premises repo, or a different solution entirely?

ECR

Buildpacks enthusiasts, in your opinion, what is it about Buildpacks that makes it a difference maker for you? What is the core incentive to you in terms of undergoing the effort of maintaining your Buildpacks in addition to your application code? (e.g. "build as code" ease-of-use, flexibility to deploy Builders across projects, consistent build environments, etc.)

I went into this in detail here: https://github.com/aws/containers-roadmap/issues/1409

hariohmprasath commented 2 years ago

👋 I work as maintainer on both the Cloud Native Buildpacks project and Paketo which provides buildpack implementations for a variety of runtimes including Java (#16) and Golang (#10). Happy to answer questions and provide support if y'all decide to go forward with buildpack support in App Runner.

Hi @ekcasey, Hope you are doing great. Thanks for volunteering and we at AWS would love to collaborate with you regarding this integration. Is there an email that we can reach out to you and go over a few questions that we have? Thanks in advance

samj1912 commented 2 years ago

@hariohmprasath you can either reach out to us on CNCF slack (https://slack.cncf.io) in the #buildpacks channel (https://cloud-native.slack.com/archives/C033DV8D9FB) or reach out to the maintainers at cncf-buildpacks@lists.cncf.io

We would love to collaborate :)

We also have office hours every Thursday at 2pm EST https://github.com/buildpacks/community#office-hours if you prefer a zoom chat :)

hariohmprasath commented 2 years ago

@hariohmprasath you can either reach out to us on CNCF slack (https://slack.cncf.io) in the #buildpacks channel (https://cloud-native.slack.com/archives/C033DV8D9FB) or reach out to the maintainers at cncf-buildpacks@lists.cncf.io

We would love to collaborate :)

We also have office hours every Thursday at 2pm EST https://github.com/buildpacks/community#office-hours if you prefer a zoom chat :)

Awesome, thanks for the quick response. Will reach out.

ekcasey commented 2 years ago

@hariohmprasath 👋!

Happy to hear this integration is potentially going forward, we are excited to help however we can :).

In addition to the communication channels @samj1912 mentioned for the Buildpacks project, if you have questions about the Paketo buildpack implementations you can find the Paketo team on Paketo slack, the Paketo mailing list or at our public working group meetings.

If you would rather, feel free to reach out to me directly in CNCF slack (probably the fastest response) or at ecasey@vmware.com.

jpillora commented 1 year ago

When a service launches "Buildpacks support," what does that mean to you?

At a high-level, I read "Buildpacks support" to means the platform will automatically convert an application directory into a curated container image.

For those of you who leverage your own Builder images, where is your preferred storage location?

Docker hub, though any Docker registry would be nice. Related, Azure App Service supports custom app image pulls via secret-reference environment variables $$Key-Vault(foo, bar) - developer experience isn't the best, though it does provide a safe and easy way to configure a docker URL and docker login credentials.

Buildpacks enthusiasts, in your opinion, what is it about Buildpacks that makes it a difference maker for you?

It's a great abstraction for a multi-level developer experience:

Easy: Getting started, I don't configure anything and with because of sane defaults – it just works TM
Medium: Want a custom runtime, I can reference an external build-pack which gives me what I want
Hard: Want a complete custom builder, I can create my own build logic contained in a image, and re-use that across my organisation

RichiCoder1 commented 1 year ago

Another interesting alternative might be https://nixpacks.com/docs. Built by Railway and Fly.io has apparently been bullish on it, so might be something that can also be considered here. Still youngish, but they've added a lot of support recently.

Edit: Also worth noting that Railway supports both so maybe AWS could consider the same https://nixpacks.com/docs/deploying/railway

aws / apprunner-roadmap

Buildpack support #11