Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Buildpack support #11

Open
purintai opened this issue May 19, 2021 · 14 comments
Open

Buildpack support #11

purintai opened this issue May 19, 2021 · 14 comments

Comments

@purintai
Copy link

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
Copy link

👍

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

@mwarkentin
Copy link

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
Copy link

ekcasey commented May 19, 2021

👋 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.

@mwarkentin
Copy link

I opened aws/containers-roadmap#1409 on the main container roadmap repo too.

@hrnatha
Copy link

hrnatha commented Sep 17, 2021

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
Copy link

jared-christensen commented Sep 18, 2021

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
Copy link

RichiCoder1 commented Sep 18, 2021

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
Copy link

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: aws/containers-roadmap#1409

@hariohmprasath
Copy link

👋 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

@sambhav
Copy link

sambhav commented Jun 4, 2022

@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 [email protected]

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
Copy link

@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 [email protected]

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
Copy link

ekcasey commented Jun 7, 2022

@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 [email protected].

@jpillora
Copy link

jpillora commented Oct 7, 2022

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:

  1. Easy: Getting started, I don't configure anything and with because of sane defaults – it just works TM
  2. Medium: Want a custom runtime, I can reference an external build-pack which gives me what I want
  3. 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
Copy link

RichiCoder1 commented Mar 9, 2023

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

@backnol-aws backnol-aws moved this to We are working on it in Roadmap Jun 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: We are working on it
Development

No branches or pull requests

10 participants