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.
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!
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.
> 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.
My view is that if you're an all-Java shop and have mature infrastructure based on JARs and WARs, stick with it. That technology is time-tested and reliable.
But if you have a mixture of technologies, the equation begins to shift towards using container images for everything.
100%. Coming up with a common pattern for deploying multiple languages is a nightmare for us. Different groups also have different patterns, all internal.
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.
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.
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.
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.
> 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.
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.
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
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).
> 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."
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 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.
I believe I understand your argument, but my experiences lead me to allocate the balance of risks differently. I think buildpacks are net win in spite of the potential problems you are pointing out.
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 ?
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).
> 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:
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.
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?
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.
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.
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.
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.
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
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.
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.
I certainly agree with you there, but I was going off the article, which gave off a strong viewpoint of "Oh, you don't actually make these builders though, are you nuts?"
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.
> 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.
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.”
throwaway may have a good point. Also, kudos on joining VMware.
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'm not doubting your experience here, but financial security firms vary hugely on their opinions and eventual implementation of compliance.
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.
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)
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.).
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.
> 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.
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).
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.
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.
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?
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.
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.
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/
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.
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.
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.
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.
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
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?
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.
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.
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.