To what extent is this interesting if I'm not in K8s?
To the extent that you run OCI images somewhere and care about (1) what's in them and (2) rapidly updating what's in them.
Paketo: Modular Buildpacks in Go
11–20 of 32 posts
Re: Paketo: Modular Buildpacks in Go
#12As someone who is not familiar with Buildpacks, I find that page particularly hard to understand. I see promising headlines like "What are Paketo Buildpacks?" just to be greeted by more unknown terms (e.g. 'Buildpacks').
You might want to explain what you are doing to an outsider and let him write the intro ;-)
Re: Paketo: Modular Buildpacks in Go
#13> written in Go I am not sure what this line is adding. It is supposed to add "runtime support". Is this doing some language specific libraries? But then they do support various other languages! Why is Go special? or that all language support is somehow made in Go? Binaries made in Go? May be that should have been left out for clarity. This is very confusing for me.
It may be an insider perspective. Early buildpacks were dominantly written in Ruby or Bash (one major one was written in Python). The Bash ones were awful . There was a generation after these, but before Paketo, which were written in Golang. Consolidating the various codebases was a big step forward and left a deep impression.
Hey, I'm one of the engineers working on this project, and this is exactly why. Golang is not 'special' just the tool we use to set up your application configuration & dependencies. We left the Golang reference on the homepage to try and avoid the 'surprise' factor of realizing the Paketo Buildpacks are not written using the language support they provide.
Re: Paketo: Modular Buildpacks in Go
#14To what extent is this interesting if I'm not in K8s?
It’s more about container images than just k8s.
Re: Paketo: Modular Buildpacks in Go
#15As someone who is not familiar with Buildpacks, I find that page particularly hard to understand. I see promising headlines like "What are Paketo Buildpacks?" just to be greeted by more unknown terms (e.g. 'Buildpacks'). You might want to explain what you are doing to an outsider and let him write the intro ;-)
Hey, I'm a PM contributing to the Paketo project. This is great feedback and something that we'll definitely work on improving on the website. I totally get that it's difficult to understand this content if you're not too familiar with Cloud Native Buildpacks.
In the meantime, are there any questions about Buildpacks and/or the Paketo project that we could help clarify? If you're interested in learning more about the buildpack architecture I'd suggest watching this Cloud Native Buildpacks intro talk that explains things pretty well - https://www.youtube.com/watch?v=SK6e_ZatOaw
Re: Paketo: Modular Buildpacks in Go
#16One thing that may not be immediately obvious: Paketo is backed by release engineering code, infrastructure[0] and know-how accumulated over 6 or so years of sustained engineering. I was lucky to work on some of it in 2014 and 2016, a year or two before the technologies directly feeding into Paketo were first developed. The engineering and infrastructure costs millions of dollars per year. And you can get the benefit…
Literally thousands of hours of playing ping-pong went into these buildpacks.
Re: Paketo: Modular Buildpacks in Go
#17Buildpacks are used by Dokku and GitLab AutoDevOps via gliderlabs/herokuish. Herokuish is a large bash script; the language autodetection can be inscrutable at times; it has opinions I don't share (e.g. PHP should not commit composer vendor, and let the buildpack do it); so I switched to Dockerfiles and don't use it any more.
Is this a replacement for herokuish? Can users use it today in those projects, or does it first need to become the default in Dokku and Gitlab? How closely do the environments/behaviours match herokuish?
Re: Paketo: Modular Buildpacks in Go
#18Ok, the headline got my attention. After looking browsing the site I just hardly know what it is about.
The only example I find is published in Github under a personal account and it only covers a hello world in node.js.
I'm sure this is a killer app but, dammit, I wish they spent some more time in docs.
I'll check it out now and then.
Re: Paketo: Modular Buildpacks in Go
#19Buildpacks are used by Dokku and GitLab AutoDevOps via gliderlabs/herokuish. Herokuish is a large bash script; the language autodetection can be inscrutable at times; it has opinions I don't share (e.g. PHP should not commit composer vendor, and let the buildpack do it); so I switched to Dockerfiles and don't use it any more. Is this a replacement for herokuish? Can users use it today in those projects, or does it fi…
Dokku Maintainer here.
Herokuish defers a lot of this work to the buildpacks.
- Language autodetection performs the bin/detect script for each buildpack in order. Last one wins, unless you have a .buildpacks file, in which case we use the multi-buildpack executor. Not sure how it can be more... scrutable, but happy to hear suggestions (my github email in my HN profile has an email for contact)
- Besides bundling Heroku's official buildpacks (as it's meant to provide a compatibility layer with Heroku), herokuish doesn't have any opinions on your source code structure. If the official Heroku buildpack doesn't do what you think it should, you can definitely fork it and change the behavior (or even pull request it so others can benefit).
I can't speak to any specific Cloud-Native Buildpack (CNB) builder such as paketo, but Dokku should have support for CNB fairly soon (it's one of my top-priorities re: new development), at which point users will be able to switch between CNB and Herokuish (rather than force folks to migrate immediately). It will become the default at some point.
For Gitlab, I believe they are or are planning on providing experimental support for CNB. You can probably already use it today if you use pack directly in your pipeline.
As far as how these systems all compare, I wrote a fairly lengthy blog post comparing the usage of herokuish vs the Cloud Foundry and Heroku builder systems that might be interesting to read: http://dokku.github.io/technology/comparing-buildpack-v3-to-...
Re: Paketo: Modular Buildpacks in Go
#20To what extent is this interesting if I'm not in K8s?
I guess if you have a case for running a html+php+nginx workload, you'd build your source code with one (or a list) of the buildpacks and create a docker image and just docker-run it.