What is your Heroku Cloud Native Buildpacks Experience? #6
hone
started this conversation in
Experiences
Replies: 2 comments 19 replies
-
What did you do?Here's my experience trying to get https://github.com/codetriage/codetriage running on the Heroku Ruby buildpack: Build outputWhat went well:Dependencies installed as expected What could be better: DatabaseThe app has no
For example, this works: https://gist.github.com/schneems/95b9387a613f4934f30f8508ef8014d8 It works! 
What could be better: JemallocThe app depends on jemalloc, it would be nice to have it on the system, or an easy way to add it. The above command shouldn't need the Do you have any questions?Less a question, more of a comment. Maybe we want to show how to expose and connect to a local database connection (or connection in another docker container) in the docs. |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Thanks for releasing this! I always loved the simplicity of a Heroku build and the auto-detection of various tools in the process. I have a small app that I tested this on and wanted to see the differences in the final image output. The biggest thing I was looking for was the size of the final image which makes it faster and easier to deal with deployment and various other tasks. What did you do?Stumbled on @schneems's article https://www.schneems.com/2024/05/01/build-a-ruby-on-rails-application-image-in-5-minutes-no-dockerfile-required/ From there: installed pack, set heroku/builder:22 as the default, packed the app. Build outputWhat went well?From the output it looks like the build went as expected, running it again utilizes some caching and reports that it successfully built the image. The build detected ruby, bundler, asset compilation which was great. What could be better?I then looked at the final image size to see the difference in size from my previously Docker built image. The pack image is 879mb, my Docker based image is 573mb. The other thing I noticed is that the image age is 44 years ago. The creation time on various other images that I've recently built is correct. Do you have any questions?
|
Beta Was this translation helpful? Give feedback.
19 replies
-
I think that #15 would have fixed the problem if all buildpacks adopted that standard. |
Beta Was this translation helpful? Give feedback.
-
|
@runesoerensen Nice! I didn't know that existed, I'll check it out. @schneems Of course, thanks for open sourcing it! I'm super excited to see where this goes. Also, good to know on the Procfile. It wasn't a big deal just not super obvious at first. Also, I'm not sure if you've used Kamal(capistrano for containers) yet but I brought up buildpacks as an alternative to Docker within GitHub Discussions basecamp/kamal#795. I think it'd be a great fit and right now a lot of the friction with Kamal ends up being about learning how to build containers, Docker, and Kamal at the same time. |
Beta Was this translation helpful? Give feedback.
-
|
One more(probably naive) question, is there anything related to a custom post-pack cleanup/removal to help reduce the image size? |
Beta Was this translation helpful? Give feedback.
-
|
@nickhammond Thanks for thinking of integration. I've thought/wondered what Kamal integration might look like, but haven't explored that space much (focused on getting the preview out). There are also other tools such as "kuby" CLI which was demo-d at the last RailsConf in portland https://github.com/smartive/kuby (but looks like development has slowed/stopped). I'm not comfortable with the current state to push "This should be the new default" for any tool, but I think it's certainly a good time to start thinking about integration and raising awareness now. Regarding cleanup/removal I opened this discussion #21. I mentioned in this note on Lobste.rs about customizing builds with buildpacks https://lobste.rs/s/fgrffn/docker_without_dockerfile_build_ruby_on#c_4tql12. They had the desire to run a cleanup script. In the long term I would like to see something like a |
Beta Was this translation helpful? Give feedback.
-
|
@schneems Agreed on it not being the new default yet but it'd be a great additional option in my opinion. I'm in the Kamal Discord and I see all of the GitHub discussions that come through and a good chunk of them are related to their Docker builds. Obviously, packs will introduce their own new set of issues but there's a lot of convention over configuration happening with packs vs. Dockerfile-based builds. Picking up I'll try and take a look at the CNB API next week if I have some time. Thanks for working on Heroku-24 and ARM support, appreciate it! |
Beta Was this translation helpful? Give feedback.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Thank you for checking our project out!
It's always a challenge as an open source project to find out how people are using your project out in the wild. We'd love to hear from you and your use case.
Let us know by adding a comment to this discussion.
Please provide as much detail as possible. You can hide unwieldy or long build output by using the details tag if you like.
Beta Was this translation helpful? Give feedback.
All reactions