7 ms·
> Containers are not used in Kubernetes or other similar orchestrators because of their support for bundling dependencies - that is a bonus at best. > Instead,
by paulgb 4y ago
> Containers are not used in Kubernetes or other similar orchestrators because of their support for bundling dependencies - that is a bonus at best.
> Instead, they are used because they are a standard way of using cgroups to tightly control what pieces of the system a process has access to
Well, sure, you get both. But the point is that needing a post-build step just to get that is accidental complexity. I'm by no means a Java fan, but the way JVM gives jars as a compile target and lets you run them with some measure of isolation is an example of how things could be.
- threeseed 4y agoWith Maven, Gradle etc you can output a Docker container from a single package command. And I don't understand this idea of using code bundles as the deployment artefact. They don't specify how the code should be run e.g. Java version, set of SSL certificates in your keystore etc. Do you really want Kubernetes to have hundreds of options for each language ? Or is it better to just leave that up to the user.
- anonymous_sorry 4y agoI think the suggestion is to use native Linux binaries with static linking of any libraries and resources in the executable. Java programs would need to be compiled as a standard ELF. I think GraalVM can do this.
- threeseed 4y agoOnly some Java/Scala programs can be compiled as a single binary. It's been a concept that has been around for years but not progressing to the point where it comes close to negating the need for the JVM in a Production environment. In the meantime containers works today and is significantly more powerful and flexible.
- krageon 4y agoThe fallback scenario just embeds the interpreter inside of the binary. That still nets you a single binary, unless I'm missing something?
- jayd16 4y agoI just don't follow the argument. You can also use Java tooling to wrap up a container image. Why is it accidental complexity that we settled on a language agnostic target that also wraps up a lot of the process isolation metadata?
- paulgb 4y agoJava is an outlier here. For most languages the process of dockerizing a codebase involves learning a separate tool (Docker). As someone who knows Docker, I get the temptation to say "who cares, just write a few lines of Dockerfile", but after talking to a bunch of developers about our container-based tool, having to leave their toolchain to build an image is a bigger sticking point than you might think.
- jayd16 4y agoBut this is begging the question. If the work was more integrated with the compiler, it would still need to be learned. If your compiler of choice spit out an deployable unit akin to an image you'd still need something akin to the Dockerfile to specify exposed ports and volumes and such, no?
- paulgb 4y agoThe Dockerfile doesn't specify volumes, those are configured at runtime. In the case of Kubernetes, they're configured in the pod spec. As for ports, EXPOSE in a Dockerfile is basically just documentation/metadata. In practice ports are exposed at runtime (if using docker) or by configuring services (if using Kubernetes), and these are unaffected by whether a port is exposed in the dockerfile. IMHO this is how it should be -- if I'm running a containerized database or web server, I want to be able to specify the port that the rest of the world sees it as, I don't want the container creator to decide that.
- jayd16 4y agowhile I admit I'm being a little loose in what would translate where in this hypothetical, none of it seems so easily cut out.