Running Java in a Container

Re:Running Java in a Container by jrudolph on Wednesday March 21, 2018 @04:09AM (#16636330)

This. I've seen container builds for Java applications broken in the described ways fail in production over and over again. Just because Docker makes building an image very easy doesn't mean that you will end up with a production ready image using three lines of code in a Dockerfile. Most of the time people don't even bother to use a non-root user to execute the jvm in their container...

That's why I feel platforms like Cloud Foundry are a much better fit for teams that don't have tons of container experience but want to get the benefits of a containerized runtime. The CF java buildpack[1] for example automatically handles OOM and heap settings calculation while building your application container.

disclaimer: co-founder at meshcloud, we offer a public cloud service for Cloud Foundry and K8s hosted in german datacenters.

    [1] https://github.com/cloudfoundry/java-buildpack

[ Parent | on HN ]

Re:Running Java in a Container by nerdwaller on Wednesday March 21, 2018 @08:49AM (#16637543)

I wrote up my experience[0] on containerizing JVM based applications a bit ago using the cloud foundry java buildpack’s memory calculator. Fortunately the JVM now has a way to respect cgroup memory[1] making it a bit simpler.

[0]: https://medium.com/@matt_rasband/dockerizing-a-spring-boot-a... [1]: https://twitter.com/codepitbull/status/934384652806221825?s=...

[ Parent | on HN ]

Re:Running Java in a Container by jacques_chester on Wednesday March 21, 2018 @07:04AM (#16636983)

In particular, the Java buildpack uses a component developed entirely to calculate JVM settings.

I am not sure what the plans are for Java 9 and 10 yet. Ben Hale works on JBP pretty much fulltime and the Spring team tend to experiment pretty early on JDKs. So I can't see it falling far behind.

[0] https://github.com/cloudfoundry/java-buildpack-memory-calcul...

[ Parent | on HN ]