Buildpacks vs. Dockerfiles
technology.doximity.com
technology.doximity.com
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.
[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?
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.
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.
Also it doesn't require a Docker daemon to build and push the image which is a huge win.
> 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.
But if you have a mixture of technologies, the equation begins to shift towards using container images for everything.
Using Docker, it doesn't matter if its Go, Python, Java, you start it with the same commands. Running in a Docker container also means you have the same platform for local development and each environment.
It also means that you can incrementally upgrade the Java version each application runs on. Not so bad for Java, but for something like Python it makes it easy and consistent.
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!
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)
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.
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.
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?
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.
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?
Composite images. Don't need a Dockerfile for each app. Rebase layers when OS layer changes (Dockerfiles would require rebuilding the whole image).
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).
"Sometimes there's a power outage, so I am forced to use candles anyhow. Therefore I should only use candles for lighting."
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.
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.
Agree to disagree?
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 ?
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.
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?
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
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.
(An argument I’m not unsympathetic to)
https://cloud.google.com/blog/products/containers-kubernetes...
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...
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.
`FROM node` etc is still relying on external communities, the buck has to stop somewhere
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.
Any kind of technology like this tends to stick out when pitching software to financial industries, who like technologies that don't have many levels of abstraction (which to them, minimizes where they get to place accountability and the surface area for issues).
Regardless, you have a point and what you say is true. But "truth" and "financially compliant", are not terms to be mixed.
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.
>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...
I'm not doubting your experience here, but financial security firms vary hugely on their opinions and eventual implementation of compliance.
In my experience, dealing with a business like Monzo and dealing with the back-office department of JPMorgan (these are not exact to me for security reasons), are worlds apart.
There are financial firms I've dealt with which will simply not sign off on something like the highest-of-high level build chain tools.
I agree! That was my point: finance folks are not universally in favour of X or Y. Within any firm there is vast heterogeneity. Just as some will never accept buildpacks, some will never accept anything less.
> 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)
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.).
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.
The Java buildpack also calculates optimal JDK memory flags based on available resources
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: https://docs.google.com/document/d/1M2PJ_h6GzviUNHMPt7x-5POU...
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.
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?
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...
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/
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.
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.
CNBs are easily composable, partly because of that experience. No more forking necessary.
1) Let's make something else so we can commit it, and get famous
2) buildpacks.
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.