[HN Gopher] Buildpacks vs. Dockerfiles
___________________________________________________________________
Buildpacks vs. Dockerfiles
Author : jwfriese
Score : 187 points
Date : 2021-02-05 20:58 UTC (3 days ago)
(HTM) web link (technology.doximity.com)
(TXT) w3m dump (technology.doximity.com)
| LukaszWiktor wrote:
| Finally some simplification in the development tooling!
| harpratap wrote:
| Buildpacks have been in the industry for many years (thanks to
| cloud foundry) but it doesn't really scale. For simple things,
| sure they are good enough but more often than not you want to
| your application to be packed in a special way and you end up
| putting more efforts than using simple Dockerfiles
| frafra wrote:
| You can always start from the generated image (which contains
| the steps used to build it) and extend it in your custom
| Dockerfile if your project gets so big, right?
| jacques_chester wrote:
| This was definitely true of previous generations, where each
| buildpack needed lots of magic to play nice with others and
| you needed to fork them if you wanted a particular feature.
|
| CNBs are easily composable, partly because of that
| experience. No more forking necessary.
| sclevine wrote:
| This is especially true of Paketo's buildpacks, which tend
| to do exactly one thing each. E.g., Paketo Node.js
| buildpack is just a configuration file that's composed of
| other buildpacks: https://github.com/paketo-
| buildpacks/nodejs/blob/main/buildp...
| mixedCase wrote:
| Am I missing something? The author seems like they just don't
| want devs to maintain their build, so why not "just use someone
| else's fit-for-purpose container image"? Whether that someone
| else is an external entity equivalent to buildpack maintainers,
| or your devops team, which should know Docker.
| itamarst wrote:
| Building Docker images is a tricky design problem, as with many
| ops tasks. The problem is due to 3 issues:
|
| 1. A Docker image is the intersection of literally 50 years of
| technology, starting from Unix in the 1970s, none of which are
| perfect. Decisions from back then still have an impact, e.g. you
| need to get signal handling right if you want shutdown to work
| (https://hynek.me/articles/docker-signals/).
|
| 2. Getting it right is all about _details_. Lots and lots of
| details, all of which need to be correct. Signal handling, where
| logs go, security updates, on and on.
|
| 3. Every organization does things slightly differently.
|
| So there are multiple approaches:
|
| == Build an abstracted tool ==
|
| A tool will support certain conventions and ways of doing
| things... but as soon as you want to diverge too much you'll
| start having issues, because it only supports its particular way
| of doing things.
|
| Pros: Easy for users.
|
| Cons: Only so long as they don't want something the tool can't
| handle.
|
| The problem is that it's quite difficult to build a tool that
| works for _all_ organizations. If you've built a custom buildpack
| for your company, you've built a custom tool, which a pretty good
| solution, but still every organization has to build their own
| tool.
|
| == Build a configuration language ==
|
| In order to support all the edge cases, you build a configuration
| language... and pretty soon it's super complicated because there
| are so many different things people want to do. In fact, you end
| up with something with complexity of Dockerfile. Probably can do
| better than "it's a shell script", but it's not going to be
| simple, and you're back to "users have to figure out all the
| details on their own".
|
| Pros: Flexible.
|
| Cons: You still need to get details right.
|
| == Template ==
|
| Here you do something tool-like: it knows about conventions, is
| customized for specific common use cases. But, you copy the code
| into you application repository, so you can then customize
| anything that doesn't fit.
|
| I have built a template for production Docker packaging of Python
| applications (https://pythonspeed.com/products/pythoncontainer/)
| and this is the approach I went with.
|
| Pros: Works most of the time out of the box, can be customized
| when it doesn't.
|
| Cons: Hard to update if you're ending up doing too many per-
| application customizations.
|
| ---
|
| Obviously this is a simplification, and these options tend to
| merge at the edges. But fundamentally it's a hard design space
| and there is no magic bullet, just tradeoffs. Longer version,
| presented slightly differently:
| https://pythonspeed.com/articles/developing-tools-for-ops/
| nerdjon wrote:
| Reading the article I am still struggling to understand why
| exactly you would transition away from something that has a ton
| of community support and a lot of people use (you are more likely
| to find a developer with Docker experience than Buildpack).
|
| This just seems like a more opinionated DockerFile that doesn't
| give you the power to change things that you may need. You will
| end up being stuck somewhere down the road and being forced to
| rewrite it as a DockerFile anyways.
|
| If you really want to make it easier for your engineers, stick
| with a DockerFile and have a couple common internal images that
| they pull from instead and just put their code in. If they need
| more flexibility they can switch to pulling a standard image (or
| you have the control to improve your base image) but you are
| sticking with Docker Syntax.
|
| Is there something I am missing here?
| jacques_chester wrote:
| > _Reading the article I am still struggling to understand why
| exactly you would transition away from something that has a ton
| of community support and a lot of people use (you are more
| likely to find a developer with Docker experience than
| Buildpack)._
|
| Cloud Native Buildpacks (CNBs) are supported by fulltime teams
| at both VMware and Salesforce/Heroku. Google now chips in, I
| expect more folks will join as time goes on. Buildpacks are
| already a CNCF project and Paketo buildpacks are a CFF project,
| openly governed and not owned by any company.
|
| Dockerfiles, by contrast, are defined by one company.
|
| > _This just seems like a more opinionated DockerFile that
| doesn 't give you the power to change things that you may
| need._
|
| You can extend CNBs pretty easily, they are designed to
| compose. Joe Kutner from Heroku has been particularly active in
| demonstrating extensions:
|
| https://github.com/jkutner/web-tty-buildpack
|
| https://github.com/jkutner/no-secrets-buildpack
|
| https://github.com/jkutner/ngrok-buildpack
|
| These are features composable with any other set of buildpacks.
| Java, Ruby, NodeJS, etc. You won't need to implement N
| ecosystems * M features. You implement N + M instead _and_ get
| to enjoy N * M value.
|
| > _If you really want to make it easier for your engineers,
| stick with a DockerFile and have a couple common internal
| images that they pull from instead and just put their code in._
|
| I've seen this done at large scale. Enormous, elaborate build
| systems, strict rules (which incidentally negate "flexibility"
| as a feature), linters, pipelines for updating things. It's
| slow, brittle, expensive and basically ... you reinvent what
| buildpacks already gives you. Except that they require more
| rebuilds vs layer rebasing and will require more disk space to
| be used for almost-but-not-quite-identical layers.
|
| Disclosure: I've worked on 2 generations of buildpack
| technology. I've worked on large Dockerfile setups. Buildpacks
| are legit.
| codefinger wrote:
| Give this a watch, and I think it may change your mind on some
| these points: https://www.youtube.com/watch?v=ofH9_sE2qy0
| corpMaverick wrote:
| Just watched that. It would solve a lot of the problems we
| have.
|
| But I don know where to start. We deploy using jenkins on AWS
| EC2 or ECS. I suppose we use the pack tool to create and then
| upload images to AWS S3 that are later deployed to ECS. Right
| ?
| nerdjon wrote:
| Watching this now. Some comments while watching.
|
| I disagree with using the Python Image as an example of an
| issue with DockerFiles. Since that is something that as me
| pulling the Python image I don't need to take care of and
| that would be the same as any "gynastics" that Buildpack may
| be taking care of behind the scenes (If I understand what you
| were showing correctly).
|
| You mention issues with images and vulnerabilities, but I
| fail to see how exactly BuildPack magically addresses this
| issue other than claiming that it just isn't an issue because
| it is "better".
|
| IMO in the beginning it sounds like you are determined to
| make managing a Dockerfile as hard as possible when it really
| is not.
|
| If one of your arguments is that having the choice of images
| (different applications have different needs even if they are
| the same language) is an issue your argument is fundamentally
| flawed. Yes there are a lot of tags for images, but they are
| fairly well organized for most of them and should not take
| long to find what you want to use.
|
| It is great that BuildPack produces a standard Docker Image.
| But nothing about this changes my opinion that this is an
| opinionated builder that when you get to the point that you
| need to do something a bit funky or weird in your application
| or build process you will end up needing to ditch it and
| build a Dockerfile anyways. I don't see what benefit this has
| to an internally built docker image that we use in our
| applications so the Dockerfiles in the dev's repos are 10
| lines max.
|
| Using a "From" image for DockerFile is just as reusable as
| Buildpack, so that is not an advantage. Again near the end
| you claim BuildPack is "safe" but why and how?
|
| If you are using Docker and your mitigation of something like
| heart bleed is "years" (for your images at least) your not
| using Docker properly and is likely a flaw in your CI
| pipeline and not something that this tool will magically fix
| since the issue is somewhere else in your pipeline (including
| people in that pipeline).
| jacques_chester wrote:
| > _But nothing about this changes my opinion that this is
| an opinionated builder that when you get to the point that
| you need to do something a bit funky or weird in your
| application or build process you will end up needing to
| ditch it and build a Dockerfile anyways._
|
| "Sometimes there's a power outage, so I am forced to use
| candles anyhow. Therefore I should only use candles for
| lighting."
| nerdjon wrote:
| I am sorry but that that analogy does not work.
|
| Using candles does not add any complexity to your
| lighting situation.
|
| But if half of my applications can use docker and half
| can (for now) use BuildPacks that adds needless
| complications to my build and dev environment for minimal
| (if any) benefit.
| jacques_chester wrote:
| I don't see it as a net increase in complexity.
| Buildpacks pay their freight and then some.
| nerdjon wrote:
| It is yet another thing to manage and train people on as
| part of a CI/CD pipeline and development workflow.
|
| It would add the complication of, if I am looking at a
| given service needing to determine if it was built with a
| DockerFile or Buildpack.
|
| And then when that application outgrows Buildpack it will
| ultimately be easier (due to knowledge that everyone
| already has working with Docker) to do whatever the
| special thing that application, tool, whatever needs in a
| DockerFile than try to understand BuildPack.
|
| Opiniated tools are great, but time and time again when
| what we need deviates slightly from the "norm" they
| become overly complicated to manage and going with the
| standard option like a DockerFile would have been better
| in the first place.
| kkapelon wrote:
| Since this is 30mins, could you please provide at TL;DW ?
| goodoldneon wrote:
| Buildpacks has some nice features, at the expense of
| deviating from an industry standard (Dockerfiles). The
| speaker implies that Dockerfiles are fine if they're fine,
| but Buildpacks is attractive if you want more control over
| your Docker image build process.
|
| Composite images. Don't need a Dockerfile for each app.
| Rebase layers when OS layer changes (Dockerfiles would
| require rebuilding the whole image).
| ojhughes wrote:
| Paraphrasing some of my other comments - "no Dockerfile" isn't
| the core benefit, it's the ability to control what base images
| are used and rebase the base images of running containers
| without needing to rebuild. It's very easy to create a
| Dockerfile that builds an image with vulnerabilities and it's
| hard to discover which containers are using the compromised
| image. Buildpacks provides a framework to ensure your fleet of
| containers use compliant images and a easy way to patch
| vulnerabilities without needing to involve the development team
| ransom1538 wrote:
| 0) Dockerfile is amazing
|
| 1) Let's make something else so we can commit it, and get famous
|
| 2) buildpacks.
| ojhughes wrote:
| That's quite a cynical and uninformed view point. Buildpacks
| have been around since 2011 in Heroku and Cloud Foundry.
|
| The core goal of the Paketo Buildpacks project is to improve
| corporate control and compliance when building OCI images. This
| is driven from the needs of large enterpise with many
| disconnected teams all pushing images.
|
| How can an enterpise ensure all those images are built using
| standardised base images? How can they rebase the base image of
| running containers without needing every team to rebuild their
| image using the latest security fix? Buildpacks solves these
| problems. "Look, no Dockerfile" is a bit of a distraction from
| the projects main purpose.
| lmarcos wrote:
| I like the other alternative Packer + ansible instead of
| Dockerfiles as explained here
| https://alex.dzyoba.com/blog/packer-for-docker/
| xrd wrote:
| This post had me at "solves the problem of massive disk space
| usage with Docker."
| ojhughes wrote:
| Compliance is a big reason for enterprises to adopt buildpacks.
| It's hard for organisations to assure all code is built using
| only approved or up to date dependencies. Dockerfile makes it
| very easy to package vulnerable libraries and difficult to verify
| which containers are vulnerable. Scanning works but better to not
| push vulnerable code in the first place
| brylie wrote:
| What are some hosting providers providing build packages support?
|
| Google and Heroku were mentioned in the article. I've also had a
| good experience with self-managed Dokku deployment. Are there any
| managed service providers that support buildpack deployment?
| xrd wrote:
| Dokku is worthy of a look. Great support for buildpacks.
| ukoki wrote:
| If you use a third-party builder like Paketo you can use
| buildpacks anywhere you can use docker images
|
| https://paketo.io/docs/builders/
| mutex007 wrote:
| NodeChef. https://www.nodechef.com/ - Supports all Cloud
| Foundry and Heroku build packs.
| dfrey1 wrote:
| A list of adopters (many of which are hosting providers) is
| here:
| https://github.com/buildpacks/community/blob/main/ADOPTERS.m...
| arthurbrown wrote:
| https://render.com is easy to use and very promising
| Lucasoato wrote:
| Which advantages does buildpacks offer vs Dockerfiles?
|
| > Familiarity with Docker and Dockerfile syntax is not universal.
| Even those with experience may not be equipped to write a
| Dockerfile that can quickly build (and rebuild) a small and
| secure image.
|
| Are there any others besides writing a dockerfile?
|
| (which can be non-trivial, I'm not underestimating it)
| mads wrote:
| I think there is rarely a reason to choose this over just a
| standard Dockerfile, which is usually not that complicated and
| probably wont change much over time once it has been
| implemented.
|
| If generating Dockerfiles needs to be scaled up somehow, I can
| understand why this would be useful. Sounds exactly like a
| problem someone like Heroku would have.
| ojhughes wrote:
| Heroku actually invented buildpacks
| jillesvangurp wrote:
| This sounds like just moving the problem. The author makes it
| seem like writing a Dockerfile is somehow such a burden on
| development teams when in reality it's a rounding error on the
| overall development time spent on a project. Ours is about five
| lines long. Copy the files, define some environment variables
| and a port, done. Not exactly rocket science.
|
| Part of the problem stems from trying to roll CI into the
| Dockerfile. Not a thing if you use, Travis-CI, Github Actions,
| the Gitlab equivalent of that, Google Cloudbuild, AWS Build,
| etc. Because it's all externalized there. Creating good
| pipelines with those is a bit of work but also nothing major.
|
| They all follow the same pattern: build pipelines defined in
| json or yaml that define steps that are effectively dockerized
| build tools. The only problem your project Dockerfile should
| solve is copying the output of that pipeline to the container.
|
| I guess a build pack would try to "standardize" CI/CD in the
| context of a very specific deploy environment and CI
| environment. Standardizing something that specific has limited
| value though. What would make sense at this point are
| dockerized build steps that work in most or all of the above CI
| systems. They all solve more or less the same problems in a
| very similar way. But of course where it gets complicated is
| the deep integration with the stuff outside the build system
| (cloud specific components, secret management, networking,
| deployment clusters, etc.).
| flavioheleno wrote:
| I think that Buildpacks help when your Dockerfile is actually
| complex due to application's dependencies or build process. I
| worked at a company where we used a multi-stage build
| Dockerfile that was quite long and tedious to maintain and
| developers would avoid keeping it up-to-date. There is also
| another point when developers are used to PaaS such as Heroku
| that already handles the "build burden" for them and thus
| Buildpacks may ease the transition to using Dockerfile-based
| builds (if needed of course).
| robin21 wrote:
| Performance is the challenge. Caching node_modules in Docker
| is a little tricky. The alternative is adding minutes to your
| build and deploy vs seconds.
| jacques_chester wrote:
| > _This sounds like just moving the problem. The author makes
| it seem like writing a Dockerfile is somehow such a burden on
| development teams when in reality it 's a rounding error on
| the overall development time spent on a project. Ours is
| about five lines long. Copy the files, define some
| environment variables and a port, done. Not exactly rocket
| science._
|
| Dockerfiles _appear_ trivial and they usually _start_
| trivial, but they don 't _remain_ trivial for long[0]. In
| particular it is very, very easy to inadvertently write a
| Dockerfile that is insecure, or wasteful of space, or
| promotes build churn, or most frequently: all three.
|
| All the tips and tricks that folks need to know in order to
| write production grade Dockerfiles are given for free in a
| buildpack. You don't need to think about the efficient
| ordering and contents of layers, the buildpack does it. You
| don't need to worry about mystery dependencies arriving via
| `wget`, buildpacks control what dials out to the outside
| world. Build churn is dropped to the minimum _necessary_
| changes, rather than the minimum _possible_ changes. Disk
| space and network traffic is saved because far more layers
| are identical.
|
| [0] See "Problem" of this document I wrote a few years ago: h
| ttps://docs.google.com/document/d/1M2PJ_h6GzviUNHMPt7x-5POU..
| .
| frafra wrote:
| There is plenty of terrible Dockerfile out there. I would
| vastly prefer to see images or Dockerfile generated by some
| well written buildpacks. I like to think about buildpacks as
| reasonably written Docker templates.
|
| Yours is 5 lines long, but many are others are more complex
| and could benefit from having a multistage (base stage with
| common dependencies, build phase with build dependencies, run
| time with the result of the previous plus some extra runtime
| dependency), setting up a custom user/group for extra
| security, optimizing execution order which vastly affect the
| time to build the image, etc.
|
| I am considering using them to make easier for my colleagues
| which are not used to Docker to containerize their
| application as well as using them as template system for
| Dockerfile handled centrally, which do not need any kind of
| manual merge/alignment afterwards.
| ojhughes wrote:
| Another advantage of buildpacks is the ability to easily
| "rebase" an image layer to update dependencies (eg JDK)
| without rebuilding the whole image.
| https://buildpacks.io/docs/concepts/operations/rebase/
|
| The Java buildpack also calculates optimal JDK memory flags
| based on available resources
| koeng wrote:
| Can I use buildpacks with Kubernetes? When I look for it online,
| I find some stuff like the Cloud Native Buildpacks, but no good
| simple tutorials on how it actually works. I remember Dokku was a
| joy to use, wish I could interact with Kubernetes like I did with
| Dokku.
| ramanujank wrote:
| Maybe this video can help: https://youtu.be/vQkngZ2OsA0
| codefinger wrote:
| Yes. The output of buildpacks is an OCI image (Docker image)
| that works with the container runtime(s) in Kubernetes
| ojhughes wrote:
| Skaffold also has first class support making it really easy
| to deploy to k8s https://skaffold.dev/docs/pipeline-
| stages/builders/buildpack...
| 0xbadcafebee wrote:
| It's pretty weird that they created this tool and configuration
| file, but neglected to allow configuring the tool via the
| configuration file. Most of the necessary _pack build_ options
| can 't be configured in the _project.toml_ file.
|
| Another downside to all this is it's still tightly wound up with
| the implementations of containers. Containers are not the end-all
| be-all of running software (most of what makes up a container is
| unnecessarily restrictive and annoying, and should actually be
| removed if we want more flexible systems). We need to focus more
| on the general abstractions needed to operate software
| components, not how specifically to run a container on a Docker
| daemon on a single host.
| samhuk wrote:
| One of the purported benefits is security, however from my
| experience in the financial software industry, I have to say -
| good luck getting your software validated where a major part of
| it's build chain is from an external "community".
|
| politelemon here is spot-on in this regard: dockerfiles provide a
| higher level of transparency. Although they _do_ have a higher
| developer-error surface area compared to more higher-level build
| chain solutions, it is absolutely necessary for many software
| industries that require stricter software validation.
| jacques_chester wrote:
| > _One of the purported benefits is security, however from my
| experience in the financial software industry, I have to say -
| good luck getting your software validated where a major part of
| it 's build chain is from an external "community"._
|
| Paketo buildpacks are the latest generation in a series of
| buildpack technogies that have made Pivotal (now VMware)
| hundreds and hundreds of millions of dollars from the finance
| industry. Heroku/Salesforce could have made much more. Google
| will almost certainly make as much.
|
| Finance security and compliance folks _love_ buildpacks. Love.
| If they loved them any more they would get tattoos and name
| their kids See Enbee.
|
| Disclosure: I work for VMware, via the Pivotal acquisition.
| I've worked on buildpacks several times.
| xyzthrowaway112 wrote:
| Not mentioned in all this buildpack hype is the fact that
| Pivotal was acquired by VMWare precisely because Pivotal's
| share price saw a single day drop of 41% in addition to a
| shareholder class action lawsuit.
|
| >The class accredits Pivotal's diminished growth to customers
| who shifted away from what they call "Pivotal's principle,
| yet outdated and inadequate offering because it was
| incompatible with the industry-standard platform."
|
| https://www.courthousenews.com/post-ipo-woes-mount-for-
| pivot...
| [deleted]
| ojhughes wrote:
| I see your point but there is nothing to stop organisations
| maintaining their own set of "trusted builders".
|
| `FROM node` etc is still relying on external communities, the
| buck has to stop somewhere
| kkapelon wrote:
| You can actually do from a private Docker image that YOU have
| created and going upwards you only hit from "scratch"
|
| so in that case there are no external communities involved. I
| am not saying that people should do this in practice, but it
| is certainly possible.
| EdSchouten wrote:
| During the last 3 years I've had the pleasure of using Bazel's
| rules_docker to generate all my container images
| (https://github.com/bazelbuild/rules_docker).
|
| In a nutshell, rules_docker is a set of build rules for the Bazel
| build system (https://bazel.build). What's pretty nice about
| these rules is that they don't rely on a Docker daemon. They are
| rules that directly construct image tarballs that you can either
| load into your local Docker daemon or push to a registry.
|
| What's nice about this approach is that image generation works on
| any operating system. For example, even on a Mac or Windows
| system that doesn't have Docker installed, you're able to build
| Linux containers. They are also fully reproducible, meaning that
| you often don't need to upload layers when pushing (either
| because they haven't changed, or because some colleague/CI job
| already pushed those layers).
|
| I guess rules_docker works fine for a variety of programming
| languages. I've mainly used it with Go, though.
| mikepurvis wrote:
| I'm a huge fan of offline generation of these kinds of things
| across the board-- one that I'm found surprisingly tricky is
| OVAs. You can create your rootfs in a loopback, and use qemu-
| img to turn that into a vmdk, but there's not a lot of
| documentation or helpers/validators out there to assist with
| producing the XML ovf metadata, and if you get it wrong in any
| way, vmware just coughs up a generic error message.
|
| One thing that is quite helpful as an example to pick through
| is the 40MB yVM from here:
| https://cloudarchitectblog.wordpress.com/2015/11/11/yvm-down...
|
| Anyone else got tips or resources for this?
| kkapelon wrote:
| > What's pretty nice about these rules is that they don't rely
| on a Docker daemon
|
| You can also use podman, img, kaniko, jib and several other
| tools that don't need a docker daemon
|
| No need to adopt a whole build system (Bazel) just to simplify
| the way you create artifacts.
| EdSchouten wrote:
| Note that I didn't just adopt the build system to build
| container images. There are also lots of other build steps
| that I wanted to do (compile Protobuf & gRPC definitions,
| build a frontend web application and build it into the
| binary, etc.).
|
| If I already want to do stuff like that and Bazel does that
| well for me, then at least in my case there was no incentive
| to use any of the tools you listed.
| tikkabhuna wrote:
| We've used Google Jib for Docker for the same reasons.
|
| It also means we don't have to think about the layout of our
| images. I know that if we went with Dockerfiles each team would
| put application code in different directories. There would be
| no consistency. Jib hides that away from us.
| jpgvm wrote:
| Jib is also great because it integrates into your existing
| build system (Bazel is a big lift for most projects,
| especially JVM ones) and takes care of the important parts of
| building a good JVM image like separating the dependencies
| into a different layer etc.
|
| Also it doesn't require a Docker daemon to build and push the
| image which is a huge win.
| e12e wrote:
| https://github.com/GoogleContainerTools/jib#what-is-jib
|
| > What is Jib?
|
| > Jib builds optimized Docker and OCI images for your Java
| applications
|
| Funny. Here I thought you could just build and deploy a jar
| if you were committed to writing Java... I suppose it does
| make sense that "all things come to docker/containers",
| though. Allowing both golang and Java services to be deployed
| in the same manner.
| kitd wrote:
| Sounds similar to podman [1] which also doesn't require a
| daemon (though you can run it with one if you like).
|
| [1] https://podman.io/getting-started/
|
| Back to the original article, I prefer dockerfile-based builds
| as it allows me to run my own tests easily on the image locally
| before uploading.
|
| Can this be done with buildkits?
| dfrey1 wrote:
| There is ongoing work with Buildpacks (specifically `pack`,
| the project CLI), to integrate better with podman, and enable
| a daemon-less workflow.
|
| We most often build it with the local docker daemon (though
| you can with a remote docker daemon), test it, and then
| publish the image.
| jacques_chester wrote:
| > _What 's pretty nice about these rules is that they don't
| rely on a Docker daemon._
|
| Neither do Cloud Native Buildpacks. The lifecycle can run as a
| regular process inside a container. The `pack` CLI tool uses
| docker as a convenient way to run those containers _on a local
| environment_. But if something else creates the containers,
| that 's fine, the lifecycle works exactly the same.
|
| FWIW there is a lot of cross-pollination of ideas between ko,
| Jib, rules_docker and CNB folks.
| kevincox wrote:
| I use Nix to do something similar:
| https://gitlab.com/kevincox/feed-test/-/blob/8b217add5fc11bb...
| bfrog wrote:
| Same, with cross compiles! Its wonderful
| an_d_rew wrote:
| We use Bazel's rules_docker as well, and I would caution
| someone evaluating it with a note from out experience.
|
| What Bazel does well (and as well as Bazel fits your use-case)
| Bazel does extremely well and is a reproducible joy to use.
|
| But if you stray off that path even a tiny bit, you're often in
| for a surprisingly inexplicable, unavoidable, far-reaching
| pain.
|
| For example, rules_docker is amazing at laying down files in a
| known base image. Everything is timestamped to the 1970 unix
| epoch, for reproducibility, but hey, it's a bit-perfect
| reproduction.
|
| Need to run one teensy executable to do even the smallest thing
| that's trivial with a Dockerfile? Bazel mist create the image
| transfer it to a docker daemon, run the command, transfer it
| back... your 1 kb change just took 5 minutes and 36 gb of data
| being tarred, gzipped, and flung around (hopefully-the-local)
| network.
|
| It may not be a dealbreaker, and you may not care, but be
| forewarned that these little surprises creep up fairly ofen
| from unexpected quarters!
| MuffinFlavored wrote:
| > But if you stray off that path even a tiny bit, you're
| often in for a surprisingly inexplicable, unavoidable, far-
| reaching pain.
|
| Not to go off on a tangent, but I feel like this is true for
| most packages/alternatives to mainstream solutions (at least
| in node.js)
| holografix wrote:
| Buildpacks are an absolute god send. Using the pack CLI and
| pointing to Google's builder image I don't care if I'm writing
| Go, Python or JavaScript and get a plain old Docker image in my
| reg.
|
| https://cloud.google.com/blog/products/containers-kubernetes...
| ris wrote:
| I have a lot of thoughts about this and could talk for a long
| time, but it comes doBoth suck. Use Nix. Problem solved.
|
| The amount that people flap around the problems involved in
| software distribution with Dockerfiles, never actually solving
| the problem and instead only ever making it more complex
| continually amazes me, and every time I come back to Nix I'm
| blown over by how simple it is in comparison.
| kohlerm wrote:
| Buildpacks IMHO suck for reproducible builds, unless you in all
| versions, and even then it can be hard to find out what you are
| really shipping. For serious (large, whatever that means)
| projects this is a huge problem. Docker/Containers solve this
| problem nicely. Developers do not have to know all the details
| about base images. Just build a decent base image for them once,
| say for JVM if that is would they need. As others have pointed
| out, there I no need to use Dockers build files approach, there
| are plenty of better alternatives out there.
| jacques_chester wrote:
| You may be thinking of earlier generations.
|
| Cloud Native Buildpacks (1) have reproducibility as a design
| constraint[0][1] and (2) produce container images as their
| output.
|
| [0] https://buildpacks.io/docs/reference/reproducibility/
|
| [1] https://medium.com/buildpacks/time-travel-with-
| pack-e0efd8bf...
| sclevine wrote:
| Additionally, Paketo's buildpacks build reproducible images
| given the same source code and buildpack versions.
| withinboredom wrote:
| Relying on something like paketo may or may not be a great idea.
| I decided to give it a go on a little PHP 8 project. I get an
| error saying PHP 8 isn't supported as it's using 0.1.0 of the PHP
| buildpack. Then I go to file an issue (especially since PHP 8 has
| been available for several months), only to discover it was
| released 4 days ago[1]. This kind of turns me off to relying on
| it. What if there was a vulnerability in PHP 8? Would I want my
| software to wait at least 4 days before I could update my
| dependencies?
|
| You give up a lot of control for "simplicity" but I'm not sure
| simple is always better. Sometimes it is, but often it's
| deceptive.
|
| [1]https://github.com/paketo-buildpacks/php-
| dist/releases/tag/v...
| ilkkal wrote:
| I'm sure it's usually just a case of "thinking while typing", but
| I find it surprising how often articles about Docker stuff get
| some basic details a bit wrong. In the very first code example
| there is a RUN instruction where the author probably meant to
| have a CMD instruction, and they talk about BuildKit and build
| cache optimisation even though that was always something to think
| about, way before BuildKit was a thing.
|
| I'm not trying to say I know everything or that the article is
| wrong or bad, but it's an observation I've made.
| codefinger wrote:
| I think this is exactly why people should use Buildpacks over
| Dockerfiles. I've seen so many Dockerfiles that are wrong, or
| even introduce security problems.
| toong wrote:
| Might have been an intentional mistake ? It fits the arguments
| pro build-packs.
| ilkkal wrote:
| The RUN? I thought about that but I don't see how that would
| work. Or is the argument that Dockerfiles are just too hard?
|
| (An argument I'm not unsympathetic to)
| mewpmewp2 wrote:
| Yeah, argument is they might be prone to errors.
| genlesperance wrote:
| Hi @ilkkal. Thank you for the note - I've corrected the
| directive!
| politelemon wrote:
| I've read through this but I'm not sure I'm seeing any advantages
| to Buildpack.
|
| First point - I see an example of a Dockerfile in TFA, but when
| it comes to the example of a Buildpack there isn't one; I just
| see a conceptual description of an abstraction. It appears that a
| lot of the inference is hidden away by use of 'detection' but is
| there magic hidden underneath? Does it allow arbitrary hacky
| steps if needed, like adding a random certificate?
|
| Second point - A Dockerfile explicitly codifies what's happening.
| I can look at it and know how the build will go or what I need to
| change. The Buildpack equivalent would be spread across many
| different files, does that sound about right?
| codefinger wrote:
| To you first point, there's probably no example of a Buildpack
| because (unlike Dockerfile) most Buildpack users don't write
| their own. They are reuseable. I'm not sure why the author
| didn't include an example of running a buildpack against an app
| though.
|
| To your second point, Buildpacks are written in code too. But
| unlike Dockerfile, they use real programming languages that you
| can write tests for.
|
| For example: https://github.com/paketo-buildpacks
| speedgoose wrote:
| Wow, that's a lot of bash boilerplate.
| codefinger wrote:
| where?
| speedgoose wrote:
| https://github.com/paketo-buildpacks/go/search?l=shell
| for example. But the situation on many Dockerfile may not
| be better I have to admit.
| jacques_chester wrote:
| These are for Github actions, taken from a shared repo:
| https://github.com/paketo-buildpacks/github-config
___________________________________________________________________
(page generated 2021-02-08 23:01 UTC)