Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Buildpacks Go Cloud Native

blog.heroku.com

Post reply on HN
Print view View original

11–17 of 17 posts

Re: Buildpacks Go Cloud Native

#11

Post by jacques_chester »

nailer wrote: post #9
jacques_chester wrote: post #5

Earlier quoted context omitted.

> Aren't they just shell scripts? They can be written in any language. I have personally worked on buildpacks written in bash, golang, ruby, python and I forget what else. > Heroku makes a big deal about them, but most Unix people have similar things floating around in ~/bin. I don't know that I agree. Could you elaborate a bit?

All the ones I've looked at have been shell, as Buildpacks are used to build systems. Python would work too. They're useful, but they're not an 'invention' or a 'technology' any more than any other bootstrap shell script is.

Nothing is new under the sun and any Turing complete system can do what any other Turing complete system can do.

There's more than "can it run a command?" here. For example, I find that vanishly few operators managing fleets with tens of thousands of containers are prepared to go along with "just run this random bash script on the VM; I promise to keep it up to date".

Re: Buildpacks Go Cloud Native

#12

Post by nailer »

jacques_chester wrote: post #11
nailer wrote: post #9

Earlier quoted context omitted.

All the ones I've looked at have been shell, as Buildpacks are used to build systems. Python would work too. They're useful, but they're not an 'invention' or a 'technology' any more than any other bootstrap shell script is.

Nothing is new under the sun and any Turing complete system can do what any other Turing complete system can do. There's more than "can it run a command?" here. For example, I find that vanishly few operators managing fleets with tens of thousands of containers are prepared to go along with "just run this random bash script on the VM; I promise to keep it up to date".

Yes, Buildpacks are trusted maintained bash scripts. In that way, as you mention, they're better than random bash scripts. That doesn't make them novel. I know you said nothing is new, and I presume you mean completely new, but there's not a single novel thing about this.

Another poster on this thread is using the term 'invented'. Another is describing them as a 'technology' that needs to be understood. Describing a bootstrap script this way sets an incredibly low bar for DevOps.

Re: Buildpacks Go Cloud Native

#13

Post by nailer »

paulddraper wrote: post #4

Hadn't heard of buildpacks before. Where do they fit into packaging picture? How do they compare to (1) VMWare images (2) Docker images (3) Debian packages? And when would you use them instead of one of these.

Non vendor answer:

It's a script. It might use packages, it might not. It builds a box with whatever runtime is necessary to run your app. It's not a new technology. The resultant image could be a container or any other kind of imaging format.

Here's the node one. It's a shell script. It sets up node. You probably already had it before you knew what a build pack was:

https://github.com/buildpack/samples/blob/master/nodejs-buil...

Re: Buildpacks Go Cloud Native

#14

Post by parasubvert »

nailer wrote: post #12
jacques_chester wrote: post #11

Earlier quoted context omitted.

Nothing is new under the sun and any Turing complete system can do what any other Turing complete system can do. There's more than "can it run a command?" here. For example, I find that vanishly few operators managing fleets with tens of thousands of containers are prepared to go along with "just run this random bash script on the VM; I promise to keep it up to date".

Yes, Buildpacks are trusted maintained bash scripts. In that way, as you mention, they're better than random bash scripts. That doesn't make them novel. I know you said nothing is new, and I presume you mean completely new, but there's not a single novel thing about this. Another poster on this thread is using the term 'invented'. Another is describing them as a 'technology' that needs to be understood. Describing a…

I think you're dramatically underestimating what a buildpack is.

The Java buildpack is a Ruby application with a modular dependency download/caching subsystem to enable both internet-connected and air-gapped enviroments, hundreds of unit and integration tests, support for runtime injection and configuration modification for TLS certificates, support for several languages including Scala , Groovy, Clojure, support for several package types, several app runtimes, etc. https://github.com/cloudfoundry/java-buildpack

The PHP buildpack is a Python application with a modular dependency download/caching subsystem to enable both internet-connected and air-gapped environments, hundreds of unit and integration tests, support for easily configuring many different PHP extensions, libraries and modules, and extension points to customize the container staging behavior. https://github.com/cloudfoundry/php-buildpack

For developers, this saves a lot of time, effort, and variance for staging their containers.

For operators, this enables a control point that simplifies CI/CD pipelines dramatically and standardizes a means of containerization across projects.

It might not be for everyone, but I think it's a useful alternative to Dockerfiles.

Re: Buildpacks Go Cloud Native

#15

Post by nailer »

parasubvert wrote: post #14
nailer wrote: post #12

Earlier quoted context omitted.

Yes, Buildpacks are trusted maintained bash scripts. In that way, as you mention, they're better than random bash scripts. That doesn't make them novel. I know you said nothing is new, and I presume you mean completely new, but there's not a single novel thing about this. Another poster on this thread is using the term 'invented'. Another is describing them as a 'technology' that needs to be understood. Describing a…

I think you're dramatically underestimating what a buildpack is. The Java buildpack is a Ruby application with a modular dependency download/caching subsystem to enable both internet-connected and air-gapped enviroments, hundreds of unit and integration tests, support for runtime injection and configuration modification for TLS certificates, support for several languages including Scala , Groovy, Clojure, support for…

Yep it's a Ruby script that deploys Java. It can run offline. And run tests. And install certs. Nice script.

> For developers, this saves a lot of time, effort, and variance for staging their containers.

Yes. This is scripting. Scripting is good. Sharing your deploy scripts with others is good too. Stop trying to pretend this is a new technology.

Re: Buildpacks Go Cloud Native

#16

Post by jacques_chester »

nailer wrote: post #13
paulddraper wrote: post #4

Hadn't heard of buildpacks before. Where do they fit into packaging picture? How do they compare to (1) VMWare images (2) Docker images (3) Debian packages? And when would you use them instead of one of these.

Non vendor answer: It's a script. It might use packages, it might not. It builds a box with whatever runtime is necessary to run your app. It's not a new technology. The resultant image could be a container or any other kind of imaging format. Here's the node one. It's a shell script. It sets up node. You probably already had it before you knew what a build pack was: https://github.com/buildpack/samples/blob/master/n…

You're looking at the sample v3 buildpack. It's simple because it's a sample.

A current v2b NodeJS buildpack can be found here: https://github.com/cloudfoundry/nodejs-buildpack

A current work-in-progress Java buildpack: https://github.com/projectriff/riff-buildpack

I've worked on Buildpacks fulltime twice now for Pivotal.

I've seen things you people wouldn't believe. Package systems on fire off the shoulder of Orion. I watched C-compilers glitter in the dark near the obscure Nokogiri-interacting-with-stray-environment-variables-if-you're-using-a-slightly-too-old-SQLite-and-the-symlink-is-broken-due-to-an-upstream-bug-that-wasn't-fixed-because-nobody-realised-this-would-happen gate.

But unlike the shell script, these moments will not be lost in time like rain. They will be shipped reliably, repeatably into production by two professional organisations prepared to assign more than a dozen engineers, watch hundreds of upstream dependencies, invest in millions of dollars of automation, test against thousands of distinct applications with tens of thousands of running containers serving billions of requests per day across multiple customers in multiple countries.

I invite you to maintain a nodejs buildpack yourself. Prove us all wrong.

Re: Buildpacks Go Cloud Native

#17

Post by nailer »

jacques_chester wrote: post #16
nailer wrote: post #13

Earlier quoted context omitted.

Non vendor answer: It's a script. It might use packages, it might not. It builds a box with whatever runtime is necessary to run your app. It's not a new technology. The resultant image could be a container or any other kind of imaging format. Here's the node one. It's a shell script. It sets up node. You probably already had it before you knew what a build pack was: https://github.com/buildpack/samples/blob/master/n…

You're looking at the sample v3 buildpack. It's simple because it's a sample. A current v2b NodeJS buildpack can be found here: https://github.com/cloudfoundry/nodejs-buildpack A current work-in-progress Java buildpack: https://github.com/projectriff/riff-buildpack I've worked on Buildpacks fulltime twice now for Pivotal. I've seen things you people wouldn't believe. Package systems on fire off the shoulder of Orion.…

I maintain cloudinit generators already that are about the same complexity and have seen things you can only dream of.

https://twitter.com/boringenormous/status/104757133137253990...

I don't have anything to prove though, since I'm not claiming I invented bootstrap scripts.

Post reply on HN