71–80 of 91 posts
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.
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 l…
> 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.
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.
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.
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-leve…
> 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 indu…
>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...
Earlier quoted context omitted.
> 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 indu…
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-standar…
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.
Earlier quoted context omitted.
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 vulnerabilit…
> 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.
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…
Give this a watch, and I think it may change your mind on some these points: https://www.youtube.com/watch?v=ofH9_sE2qy0
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 ?
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 l…
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.
> 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.
Earlier quoted context omitted.
> 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."
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.