by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Chanseok Oh
    @chanseokoh
    @nes-a-cti that's not true. If you set your own entrypoint, Jib will always use it (whether it's war or not).
    However, note that if you set your own entrypoint, jvmFlags will be ignored. (That's logical, because you are defining the entrypoint yourself instead of having Jib construct one for you.)
    @olanowak the closest thing you can have is to use the <extraDirectories> feature, which allows you to put arbitrary files. Here's an interesting example that downloads and installs a Java debug agent.
    Andreas Höhmann
    @ahoehma
    Hi. Have someone a running gitlab-ci build example where maven-jib-plugin push the image to Amazon ECR?
    Nes
    @nes-a-cti

    @nes-a-cti that's not true. If you set your own entrypoint, Jib will always use it (whether it's war or not).

    @chanseokoh Thanks for your help on this. :) I am getting following message for jib.

    Screenshot 2020-07-06 at 11.48.36 AM.png
    Screenshot 2020-07-06 at 11.48.47 AM.png
    Chanseok Oh
    @chanseokoh
    @nes-a-cti yeah, jvmFlags are ignored for a WAR project. However, you can set entrypoint to what you like.
    Nes
    @nes-a-cti
    Thanks @chanseokoh :)
    Andreas Höhmann
    @ahoehma
    Hi all I got it running ... gitlab-ci, maven-build, jib-maven-plugin push to ecr :D
    The trick was to install the tools for ecr-helper (gitlab-before_script:apt-get -qq -y install awscli amazon-ecr-credential-helper), then do an on-the-fly aws configure and then just call jib:build with -Djib.to.credHelper=ecr-login :P
    Chanseok Oh
    @chanseokoh
    @ahoehma thanks for sharing the tip!
    mohanrao
    @mohanrao
    Hi I am getting Base image 'gcr.io/distroless/java:11' does not use a specific image digest - build may not be reproducible
    from the message it seems it is very clear to specify the version
    how to specify it any example?
    mohanrao
    @mohanrao
    i found that i can set jib.from.image to this gcr.io/distroless/java@sha256:856b4970a6bb9a1a5e13be6028ba4afa0b9111550f7bdf7222a8d0b0fa78e174
    is there are any better mechanism exist ?
    Chanseok Oh
    @chanseokoh
    @mohanrao using a SHA digest is the only and right way to pin down to a specific image (unless you control the base image repository and your management policy is to never advance an image tag). Note that you can use both tag and digest (e.g., gcr.io/distroless/java:11@sha256:...) but beware that the tag in that case only serves as documentation and will have no effect.
    Kaatee
    @Kaatee

    Hi! I am trying to build my jib app using base image. My configuration:

    <plugin>
                            <groupId>com.google.cloud.tools</groupId>
                            <artifactId>jib-maven-plugin</artifactId>
                            <configuration>
                                <skip>false</skip>
                                <from>
                                    <image>xxx:latest</image>
                                </from>
                                <allowInsecureRegistries>true</allowInsecureRegistries>
                            </configuration>
                            <executions>
                                <execution>
                                    <id>build-local-image</id>
                                    <phase>package</phase>
                                    <goals>
                                        <goal>dockerBuild</goal>
                                    </goals>
                                </execution>
                            </executions>
                        </plugin>

    my base docker image:

    FROM openjdk:11-jre-slim
    
    RUN apt-get update && apt-get install -y --no-install-recommends apt-utils && \
        apt-get install -qq -y dmidecode ipmitool nfs-common procps sysstat samba

    I cannot see installed libraries in my docker image (it looks like jib doesn't use my image). Can it be caused by INFO log "The base image requires auth. Trying again for openjdk:11.0.4-jre-slim...". If it isn't caused by this auth issues, what can be the reason?

    Chanseok Oh
    @chanseokoh
    @Kaatee Jib doesn't use Docker engine (daemon) or Dockerfile. It can build an image without Docker on your system.
    Oh, sorry. I think I misunderstood your question.
    Where did you store your base image that was built with the Dockerfile?
    I don't think you put the correct base image reference in <from><image>, because the log says Trying again for openjdk:11.0.4-jre-slim.... It must be that you put <from<image>openjdk:11.0.4-jre-slim instead of specifying your own base image.
    prakashul
    @prakashul
    Hi folks. I am running a Jenkins master slave setup on Kubernetes (1.14). The benefit of jib is seen best in reusing the image cache. What would be the best way to share the docker cache when the agent pods are ephemeral ? I'm looking something on the lines of Kaniko that can use ECR as a cache repo. Since EBS does not support ReadWriteMany as a volume mount option. Using EFS/NFS seems counter productive as it increases the build time. due to writes over network.
    Chanseok Oh
    @chanseokoh
    @prakashul in practice, Jib doesn't need to download base images (as long as the target repository has them, which will be the case unless you have never pushed any image to the repo), so there's not much point caching the base image layers. That leaves us with caching application layers (<project root>/target/jib-cache in Maven or <project root>/build/jib-cache in Gradle; they are configurable), but that's per-application cache, so depending on your situation, it may not have much benefit caching them.
    Especially when your application layers are small.
    And, because it's per-application cache, unless you build the same application concurrently, maybe you can use a ReadWriteOnce volume if you really want to cache application layers?
    Clayton Walker
    @Sineaggi
    Hey all! I'm using the gradle jlink and jib plugins to generate docker images. I'm looking for some feedback on where this system could be improved. Currently, there are a few issues I've come across. https://pastebin.com/ubWTexZG
    To being with, I noticed there isn't a trivial way to add a dependency between the default gradle jib stage and another jib stage. We have to route through a combination of jib.from.image = "tar://$buildDir/image.tar" and Containerizer.to(TarImage.at(File(buildDir, "image.tar").toPath()).named("myimage")) to properly create a base layer
    Secondly there doesn't seem to be a simple way to set up a symlink, like is done for the java distroless images symlinks = { "/usr/bin/java": java_executable_path, },
    Thirdly (this is less impactful) file permissions aren't kept, which means we have to manually specify executable bit on binaries .addEntryRecursive(bin.first(), AbsoluteUnixPath.get("/usr/lib/jdk-14.0.1/bin/")) { _, u -> if (u in binaries) { FilePermissions.fromOctalString("755") } else { FilePermissions.fromOctalString("644") } }
    Clayton Walker
    @Sineaggi
    Related to the symlink issue, we can't append to pre-existing environment variables. That means if we want to add to the PATH, we have to manually read out the pre-existing path, then manually set it in the child image .addEnvironmentVariable("PATH", "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/busybox:/usr/lib/jdk-14.0.1/bin")
    Finally, (and this isn't that bad) its rather awkward to specify additional jib images in gradle. Using a combination of doLast and dependsOn is a bit unwieldy. Perhaps there is room for an extendable GenericJibTask whose configuration inputs take a JibContainerBuilder and a to function that would take a TarImage, DockerDaemonImage or RegistryImage.
    Chanseok Oh
    @chanseokoh
    @Sineaggi for putting the JRE and setting permissions, how about adding them through jib.extraDirectories? And although not documented, jib.extraDirectories.permissions can take GoogleContainerTools/jib#2345. Note once an image is built, there's no such notion as "base image" or "application layers".
    Chanseok Oh
    @chanseokoh
    I bet using jib.extraDirectories will significantly cut down the whole build time, as the JRE layer will be fully cached and doesn't need to be rebuilt. OTOH, your current configuration requires assembling a tarball containing the entire base image and unpacking it on every build.
    Clayton Walker
    @Sineaggi
    So the extraDirectories is a bit strange, because it ends up placing the jdk files as the final layer
    Perhaps if the extraDirectories had a 'hint' for where they should be placed, in this case I'd hope the jdk is least frequently updated (and more easily cached across versions and even applications)
    It is significantly shorter though, thanks for that hint @chanseokoh
    jib {
        extraDirectories {
            paths {
                path {
                    setFrom("$buildDir/jre/basetest-linux-x64/")
                    into = "/usr/lib/jdk-14.0.1"
                }
            }
            permissions = mapOf(
                "/usr/lib/jdk-14.0.1/bin/java" to "755",
                "/usr/lib/jdk-14.0.1/bin/keytool" to "755"
            )
        }
        from {
            image = "gcr.io/distroless/java-debian10:base-debug"
        }
        to {
            image = "finalimage"
        }
    }
    Clayton Walker
    @Sineaggi
    Also still kinda unsure on how to handle the symlink for the executable, or appending to the pre-existing PATH variable
    Chanseok Oh
    @chanseokoh
    From a technical standpoint, if you think about it, the order of layers doesn't matter. If doesn't affect caching or performance in any way, so I wouldn't be concerned.
    (BTW, I believe you can do permissions = ['.../java': '755', ...] in Gradle. Not sure about Kotlin though.)
    Clayton Walker
    @Sineaggi
    Does the order not matter? I was under them impression higher layers were dependent on lower layers
    Chanseok Oh
    @chanseokoh
    The order matters when layers have same directories or files.
    But in your case, that wouldn't matter. You have no other layers containing /usr/lib/jdk-14.0.1.
    Clayton Walker
    @Sineaggi
    Oh neat. Yeah, the jdk should be in a unqiue location in this case.
    Chanseok Oh
    @chanseokoh
    BTW, the symlink stuff is an issue though. It seems there's no way to create a symlink with Jib. We know the limitation.
    BTW, we have recently made Jib extensible, so if you are interested, take a look at https://github.com/GoogleContainerTools/jib-extensions
    But I think Jib extensions still won't be able to take care of the symlink and the PATH issues.
    Clayton Walker
    @Sineaggi
    Thanks for the link, I'll look into it.