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
    No, I don't see it.
    $ mvn --file=pom-test.xml jib:build
    [INFO] Scanning for projects...
    [INFO] 
    [INFO] -------------------------< example:helloworld >-------------------------
    [INFO] Building helloworld 1
    [INFO] --------------------------------[ jar ]---------------------------------
    [INFO] 
    [INFO] --- jib-maven-plugin:1.7.1-SNAPSHOT:build (default-cli) @ helloworld ---
    [INFO] 
    [INFO] Containerizing application to localhost:5000/test/image...
    [WARNING] Base image 'francium25/base' does not use a specific image digest - build may not be reproducible
    [INFO] The base image requires auth. Trying again for francium25/base...
    [INFO] Using base image with digest: sha256:c6ecf89744e4da0a9ba41adb62172b7cfb2d48d140687950a039c1fd89fce8c1
    [INFO] 
    [INFO] Container entrypoint set to [java, -cp, /app/resources:/app/classes:/app/libs/*, example.HelloJarWorld]
    [INFO] 
    [INFO] Built and pushed image as localhost:5000/test/image
    [INFO] Executing tasks:
    [INFO] [===========================   ] 90.0% complete
    [INFO] > launching layer pushers
    [INFO] 
    [INFO] ------------------------------------------------------------------------
    [INFO] BUILD SUCCESS
    [INFO] ------------------------------------------------------------------------
    [INFO] Total time:  2.015 s
    [INFO] Finished at: 2019-11-08T14:52:54-05:00
    [INFO] ------------------------------------------------------------------------
    My settings.xml:
        <server>
          <id>localhost:5000</id>
          <username>something</username>
          <password>another</password>
        </server>
    And if I enable DEBUG log:
    [DEBUG] TIMING  Retrieving registry credentials for localhost:5000                                                                                                                               
    [DEBUG] Using Maven settings for localhost:5000                                                                                                                                                  
    [DEBUG] TIMED   Retrieving registry credentials for localhost:5000 : 0.0 ms
    Lionel Fleury
    @lionelfleury
    What is your `
    Chanseok Oh
    @chanseokoh
    Maven version? 3.6.0
    Lionel Fleury
    @lionelfleury
    Do you also have a repositories.repository.id matching?
    Apache Maven 3.6.2 (40f52333136460af0dc0d7232c0dc0bcf0d9e117; 2019-08-27T17:06:16+02:00)
    I'm not running this for localhost but for an external host. So the repository.id has to be defined as well
    And given maven matching id keys. it has to be the same
    so having :port is a "problem"/issue
    [WARNING] Some problems were encountered while building the effective model for executors-common:jar:HEAD-SNAPSHOT
    [WARNING] 'repositories.repository.id' must not contain any of these characters \/:"<>|?* but found :
    Chanseok Oh
    @chanseokoh
    I don't have <repositories> at all. This won't have any effect. Jib only looks into <servers>. I think for the purpose of retrieving credentials, you can just set <server>.
    Lionel Fleury
    @lionelfleury
    So you are right for the server.id part. my bad.
    Chanseok Oh
    @chanseokoh
    No worries.
    Lionel Fleury
    @lionelfleury
    but then it has to match the repositories part given maven std approach
    Chanseok Oh
    @chanseokoh
    I see... I don't know the standard interactions between repositories and servers, but can't you just have an extra <server><id>registry:80 not matching any repository?
    For the purpose of putting credentials there only.
    Lionel Fleury
    @lionelfleury
    yes this you could...
    but maven std enforce you to match these ids between server part and repository part
    Chanseok Oh
    @chanseokoh
    Okay, I think you have a point.
    Lionel Fleury
    @lionelfleury
    which in short means you would have to create/add a double entry just for jib to be happy
    Chanseok Oh
    @chanseokoh
    Could you file an issue? I don't actually know what repositories does and why servers and they have to match for what.
    Lionel Fleury
    @lionelfleury
    where maven just expects to have an id matching for your company.registry server or whatever id you would like to give it actually
    again retrieving the server.id and registries.registry.id to match for auth (std maven behavior)
    Sure I can fill an issue for that
    Chanseok Oh
    @chanseokoh
    Cool. Thanks. We'll look into them and think about how to resolve it.
    Lionel Fleury
    @lionelfleury
    created. Thx for your help and pointed this out :)
    Björn Magnusson
    @bjornmagnusson

    got an older base image based on a older revision of centos/systemd where a volume is defined using [[ <volume-path> ]] pattern. this does not seem to work at all
    Is that supposed to be supported?
    Caused by: com.google.cloud.tools.jib.image.json.BadContainerConfigurationFormatException: Invalid volume path: [

    rebasing the image on the very latest centos/systemd seems to work where the same volume is defined as [ <volume-path> ]

    Chanseok Oh
    @chanseokoh
    @bjornmagnusson what's the image? I'd like to look inside the image configuration.
    Björn Magnusson
    @bjornmagnusson
    it´s stored on a private registry...but docker image inspect gives
    [ { "Id": "sha256:041cdb9a6ac12f5bbaf9454482b01c2f16997a6f75b83c31aaf2388265d87c26", "RepoTags": [ "docker.ucr.uu.se/systemd_centos7:latest" ], "RepoDigests": [ "docker.ucr.uu.se/systemd_centos7@sha256:0d18ae1394c334a1bd37b3403dc576c8ee1897405c94d884275706a8129ee747" ], "Parent": "", "Comment": "", "Created": "2016-02-04T13:16:56.170982074Z", "Container": "52da2833052c468c889bfb4c4225d5a621000e00aeda7f255d77d3280830dde4", "ContainerConfig": { "Hostname": "f77e60ad5dfc", "Domainname": "", "User": "", "AttachStdin": false, "AttachStdout": false, "AttachStderr": false, "Tty": false, "OpenStdin": false, "StdinOnce": false, "Env": [ "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin", "container=docker" ], "Cmd": [ "/bin/sh", "-c", "#(nop) CMD [\"/bin/sh\" \"-c\" \"[“/usr/sbin/init”]\"]" ], "Image": "bbaf7a675961d81b39dcf8e74689c3c373c28831a6bc8748a53e47dc769d7e68", "Volumes": { "[": {}, "]": {}, "“/sys/fs/cgroup”": {} }, "WorkingDir": "", "Entrypoint": null, "OnBuild": [], "Labels": { "build-date": "2015-12-23", "license": "GPLv2", "name": "CentOS Base Image", "vendor": "CentOS" } }, "DockerVersion": "1.7.1", "Author": "", "Config": { "Hostname": "f77e60ad5dfc", "Domainname": "", "User": "", "AttachStdin": false, "AttachStdout": false, "AttachStderr": false, "Tty": false, "OpenStdin": false, "StdinOnce": false, "Env": [ "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin", "container=docker" ], "Cmd": [ "/bin/sh", "-c", "[“/usr/sbin/init”]" ], "Image": "bbaf7a675961d81b39dcf8e74689c3c373c28831a6bc8748a53e47dc769d7e68", "Volumes": { "[": {}, "]": {}, "“/sys/fs/cgroup”": {} }, "WorkingDir": "", "Entrypoint": null, "OnBuild": [], "Labels": { "build-date": "2015-12-23", "license": "GPLv2", "name": "CentOS Base Image", "vendor": "CentOS" } }, "Architecture": "amd64", "Os": "linux", "Size": 222716178, "VirtualSize": 222716178, "GraphDriver": { "Data": { "LowerDir": "/var/lib/docker/overlay2/7849ee009d3abc59b3a670b3c287644098b1979e172fa5e17d97762c3d453eb4/diff:/var/lib/docker/overlay2/cb6958d38617f324bd8cd885faf42eddc40c067ad8f04285169161f93cf5591d/diff:/var/lib/docker/overlay2/ffcc068c606d617b8425026da0de642f43ed7963587ec9ce6ba0c367ba55e0d5/diff:/var/lib/docker/overlay2/bc3a360e3204d4e68102720f0ad9e23fde959f7cd0d2b310938bd9876d199def/diff:/var/lib/docker/overlay2/143154df753164421347029c4af3e29fb4363c1cefc2563d108e45a13c5c9409/diff:/var/lib/docker/overlay2/210507dd431e35b18b87b37751672950f1bcf2cd72ed9d7bd6b0d5a1fbd39bd8/diff:/var/lib/docker/overlay2/a0a0f51f597026d003a4e6c9246b996bff4f1e01f46243dddaa4f442db8073f0/diff:/var/lib/docker/overlay2/c5a6f9f60f46cb8944ad73042fecc0f740071b2cd844a9533d6946bdde08f56e/diff", "MergedDir": "/var/lib/docker/overlay2/67097a99d1af0d58e1c08a22f54708675f1f537ea971f58d57f0637cd6b774b4/merged", "UpperDir": "/var/lib/docker/overlay2/67097a99d1af0d58e1c08a22f54708675f1f537ea971f58d57

    and docker image history gives...
    `IMAGE CREATED CREATED BY SIZE COMMENT
    sha256:041cdb9a6ac12f5bbaf9454482b01c2f16997a6f75b83c31aaf2388265d87c26 3 years ago /bin/sh -c #(nop) CMD ["/bin/sh" "-c" "[“/usr/sbin/init”]"] 0B

    <missing> 3 years ago /bin/sh -c #(nop) VOLUME [[ “/sys/fs/cgroup” ]] 0B

    <missing> 3 years ago /bin/sh -c yum -y install systemd; yum clean all; (cd /lib/systemd/system/sysinit.target.wants/; for i in ; do [ $i == systemd-tmpfiles-setup.service ] || rm -f $i; done); rm -f /lib/systemd/system/multi-user.target.wants/;rm -f /etc/systemd/system/.wants/;rm -f /lib/systemd/system/local-fs.target.wants/; rm -f /lib/systemd/system/sockets.target.wants/udev; rm -f /lib/systemd/system/sockets.target.wants/initctl; rm -f /lib/systemd/system/basic.target.wants/;rm -f /lib/systemd/system/anaconda.target.wants/*; 1.67MB

    <missing> 3 years ago /bin/sh -c yum -y update; yum clean all 24.4MB

    <missing> 3 years ago /bin/sh -c #(nop) ENV container=docker 0B

    <missing> 3 years ago /bin/sh -c #(nop) CMD ["/bin/bash"] `

    Chanseok Oh
    @chanseokoh

    Looks like the volume field in the container configuration itself is a wrong value. I am not sure if the Dockerfile directive VOLUMNE [[ path ]] had worked with an old Docker CLI, but the value in the JSON is just not right. It ended up being:

    "Volumes": {
        "[": {},
        "]": {},
        "“/sys/fs/cgroup”": {}
    }

    which is a map from string (volume path) -> literal {}, meaning that it defines three volume paths (map entries): [, ], “/sys/fs/cgroupâ€. And of course, ], and [ are not a valid absolute UNIX path. (And in fact, “/sys/fs/cgroup” doesn't start with / and this will cause Jib to fail as it is not an absolute path.)

    And those weird characters †seem like they shouldn't really be intended.
    Björn Magnusson
    @bjornmagnusson
    @chanseokoh that makes sense. thanks for looking into it!
    Björn Magnusson
    @bjornmagnusson
    Caused by: com.google.cloud.tools.jib.image.LayerPropertyNotFoundException: Diff ID not available for digest-only layer
        at com.google.cloud.tools.jib.image.DigestOnlyLayer.getDiffId (DigestOnlyLayer.java:50)
        at com.google.cloud.tools.jib.builder.steps.PreparedLayer.getDiffId (PreparedLayer.java:93)
        at com.google.cloud.tools.jib.image.json.ImageToJsonTranslator.getContainerConfiguration (ImageToJsonTranslator.java:142)
        at com.google.cloud.tools.jib.builder.steps.PushContainerConfigurationStep.call (PushContainerConfigurationStep.java:63)
        at com.google.cloud.tools.jib.builder.steps.StepsRunner.lambda$pushContainerConfiguration$9 (StepsRunner.java:359)
        at com.google.common.util.concurrent.TrustedListenableFutureTask$TrustedFutureInterruptibleTask.runInterruptibly (TrustedListenableFutureTask.java:125)
        at com.google.common.util.concurrent.InterruptibleTask.run (InterruptibleTask.java:69)
        at com.google.common.util.concurrent.TrustedListenableFutureTask.run (TrustedListenableFutureTask.java:78)
        at java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1128)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:628)
        at java.lang.Thread.run (Thread.java:834)
    happens when building daemon-less (jib:build) but works fine when building to docker daemon
    base image updated to current centos/systemd:latest using sha256 pattern
    Chanseok Oh
    @chanseokoh
    Now that seems like a bug. Are you using a base image in a remote registry?
    Chanseok Oh
    @chanseokoh
    A serious bug.
    Chanseok Oh
    @chanseokoh

    I think I figured out under what conditions this will happen.

    1. You used --offline OR you used a digest for referencing the base image (e.g., my-base@sha256:xxx).
    2. AND the registry holding the base image returns the old V2 Schema 1 manifest.

    It is still a bug on our side, but if you break any of the conditions above, I think you can avoid this bug.

    For example, you reference the base image with a tag (e.g., my-base or my-base:bionic), or you make the registry return the V2.2 manifest or use a different registry.
    Chanseok Oh
    @chanseokoh

    BTW, v2 Schema1 manifest is deprecated in Docker: https://docs.docker.com/engine/release-notes/#19030

    Deprecate image manifest v2 schema1 in favor of v2 schema2. Future version of Docker will remove support for v2 schema1 althogether. moby/moby#39365

    So I suggest trying to migrate to v2 scheme2 early anyway.

    Chanseok Oh
    @chanseokoh
    Hmmm.... looking at the code again, I'm not sure if --offline or a digest referencing is required. It may happen whenever the manifest is the legacy V2 Schema 1. Needs to look into it further. But definitely, this is when the manifest is V2.1.
    Chanseok Oh
    @chanseokoh
    @bjornmagnusson filed GoogleContainerTools/jib#2147
    Chanseok Oh
    @chanseokoh
    @bjornmagnusson I cannot reproduce it. There must be something more about your setup. Could you update the issue with more details?
    Chanseok Oh
    @chanseokoh
    Never mind. I can reproduce it, and there's a simpler workaround if upgrading the registry to return V2.2 is cumbersome. Check out the issue link.
    Björn Magnusson
    @bjornmagnusson
    @chanseokoh just tried the work-around, seems to be working fine :)
    will look into promoting registry updates
    registry is the docker/registry project, and it is indeed returning v2.1 per default but supports v2.2 when configured