8 ms·

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 Dockerf

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.

jpgvm 6y ago
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.
e12e 6y ago
https://github.com/GoogleContainerTools/jib#what-is-jib https://github.com/GoogleContainerTools/jib#what-is-jib > 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.
- jacques_chester 6y ago
  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.
  - tikkabhuna 6y ago
    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.

jpgvm 6y ago

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.

e12e 6y ago

https://github.com/GoogleContainerTools/jib#what-is-jib https://github.com/GoogleContainerTools/jib#what-is-jib > 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.

jacques_chester 6y ago
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.
- tikkabhuna 6y ago
  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.