GoogleContainerTools / jib

🏗 Build container images for your Java applications.
Apache License 2.0
13.67k stars 1.44k forks source link

Building docker image of spring boot #2207

Closed nithinkota closed 4 years ago

nithinkota commented 4 years ago

I have logged in to docker hub through command prompt using docker login. Now I am trying to generate and push image to docker hub using command gradlew jib --image=demo:0.0.1-SNAPSHOT .I am getting error

Task :jib FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':jib'.
> com.google.cloud.tools.jib.plugins.common.BuildStepsExecutionException: Build
image failed, perhaps you should make sure your credentials for 'demo:0.0.1-SNAP
SHOT' are set up correctly.
chanseokoh commented 4 years ago

Hi @nithinkota,

Are you really a maintainer of the offcial repo demo on Docker Hub? I doubt it, because pushing a tag 0.0.1-SNAPSHOT to an official repo does not make sense to me.

nithinkota commented 4 years ago

I am new to docker.I started learning.This is my first project with spring boot docker. I need to give it as latest?

raizoor commented 4 years ago

@nithinkota ,

Can you build your APP and package your container locally, least push the image without JIB to this registry, using docker? I think the problem here isn't JIB.

I think @chanseokoh say that you are try to use an official repo only to test your lab, so, it's strange. Se that, for example: If i need do the same thing that you, I'll create a repo like this:

raizor/demoSpring:0.0.1
chanseokoh commented 4 years ago

Yeah, @raizoor is right. You should probably say something like --image=nithinkota/demo:0.0.1-SNAPSHOT (assuming nithinkota is your Docker Hub username). In this case, nithinkota/demo is your image repository on Docker Hub. demo simply as it is with no "hierarchy" is another repository that you don't have control over.

nithinkota commented 4 years ago

@raizoor I am able to push the image without jib.While push the image with jib getting exception.

nithinkota commented 4 years ago

@raizoor @chanseokoh

I changed bit code in build.gradle as

jib {
  to {
    image = 'nithin4325/demo'
    auth {
      username = 'nithin4325'
      password = xxxxxxx
    }
}
}

Now when I give gradlew jib getting excption

D:\demo>gradlew jib

> Task :jib

Containerizing application to nithin4325/demo...

Container entrypoint set to [java, -cp, /app/resources:/app/classes:/app/libs/*,
 com.example.demo.DemoApplication]
Executing tasks:
[===========================   ] 90.0% complete
> building image to registry

> Task :jib FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':jib'.
> com.google.cloud.tools.jib.plugins.common.BuildStepsExecutionException: Build
image failed, perhaps you should make sure your credentials for 'registry-1.dock
er.io' are set up correctly.`
raizoor commented 4 years ago

On Google, don't you need to use the registry name on container image name too?

My example (i'm not use google): harbor.mysubnet.net/raizorDemo:snapshot

nithinkota commented 4 years ago

@raizoor

I already logged in to dockerhub through command prompt using docker login.

I tried with the following approches

jib { to { image = 'nithin4325/demo' //image = 'registry.hub.docker.com/nithin4325/demo' //image = 'docker.io/nithin4325/demo' //image = 'hub.docker.com/nithin4325/demo' //image = 'registry.hub.docker.com/library/nithin4325/demo' auth { username = 'nithin4325' password = xxxxxxx } } }

I tried all the above approaches.Still getting same Error.I didn't understand where I am doing wrong.

chanseokoh commented 4 years ago

nithin4325/demo should work. If docker push nithin4325/demo works, then you don't need to configure auth in Jib with the auth { username = ... password = ... } section. Jib will be able to retrieve Docker config credentials (stored in ~/.docker/config.json). If removing the auth {} section works, it probably means you specified a wrong username or password.

nithinkota commented 4 years ago

@chanseokoh

docker

Before docker login config.json:

{
    "auths": {},
    "HttpHeaders": {
        "User-Agent": "Docker-Client/19.03.1 (windows)"
    },
    "credsStore": "wincred"
}

After docker login config.json:

{
    "auths": {
        "https://index.docker.io/v1/": {}
    },
    "HttpHeaders": {
        "User-Agent": "Docker-Client/19.03.1 (windows)"
    },
    "credsStore": "wincred"
}

When I logged in through command prompt using docker login I am able push image image with docker push nithin4325/demo but not withjibDockerBuild

chanseokoh commented 4 years ago

Can you add credHelpers: like the following and see if it works?

{
    "auths": {
        "https://index.docker.io/v1/": {}
    },
    "HttpHeaders": {
        "User-Agent": "Docker-Client/19.03.1 (windows)"
    },
    "credHelpers": {
        "https://index.docker.io/v1/": "wincred"
    },
    "credsStore": "wincred"
}
chanseokoh commented 4 years ago

And which version of Jib are you using? Recent versions should say

> com.google.cloud.tools.jib.plugins.common.BuildStepsExecutionException: Build image failed, perhaps you should make sure your credentials for 'registry-1.docker.io/francium25/test' are set up correctly. See https://github.com/GoogleContainerTools/jib/blob/master/docs/faq.md#what-should-i-do-when-the-registry-responds-with-unauthorized for help

but looks like your build just returns

> com.google.cloud.tools.jib.plugins.common.BuildStepsExecutionException: Build image failed, perhaps you should make sure your credentials for 'demo:0.0.1-SNAP SHOT' are set up correctly.

nithinkota commented 4 years ago

@chanseokoh After adding helpers Image built successfully but not pushed to docker hub. jib version:1.4.0

chanseokoh commented 4 years ago

Using Jib 1.8.0, can you upload the Gradle build log when running with the --stacktrace --info parameters?

raizoor commented 4 years ago

@nithinkota

gradle jibDockerBuild don't send your image to registry. It's like you builds locally.

nithinkota commented 4 years ago

@chanseokoh @raizoor By mistake I tried gradle jibDockerBuild .Still same error with gradle jib(1.4.0).I will give logs with 1.8.0 jib

raizoor commented 4 years ago

JIB 1.4.0 it's not good version to use, exactly for problems by auth. Try 1.6.1 or last.

TadCordle commented 4 years ago

I'll reopen this issue since the problem doesn't seem to be resolved yet.

nithinkota commented 4 years ago

@raizoor

Two times I tried to build

Logs:

`Skipping push; BLOB already exists on target registry : digest: sha256:ccb21c490
7efe2fadc91e653e18296884bd25207e9fa4fa54226fb79a4a70cba, size: 1613
I/O error for image [registry-1.docker.io/nithin4325/demo]:
    The target server failed to respond
Executing tasks:
[=========================     ] 82.5% complete
> launching layer pushers

> Task :jib FAILED
:jib (Thread[Execution worker for ':' Thread 2,5,main]) completed. Took 18 mins
38.51 secs.

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':jib'.
> com.google.cloud.tools.jib.plugins.common.BuildStepsExecutionException: The ta
rget server failed to respond

* Try:
Run with --debug option to get more log output. Run with --scan to get full insi
ghts.

* Exception is:
org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':jib'.
        at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.la
mbda$executeIfValid$1(ExecuteActionsTaskExecuter.java:187)
        at org.gradle.internal.Try$Failure.ifSuccessfulOrElse(Try.java:263)
        at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.ex
ecuteIfValid(ExecuteActionsTaskExecuter.java:185)
        at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.ex
ecute(ExecuteActionsTaskExecuter.java:166)
        at org.gradle.api.internal.tasks.execution.CleanupStaleOutputsExecuter.e
xecute(CleanupStaleOutputsExecuter.java:109)
        at org.gradle.api.internal.tasks.execution.FinalizePropertiesTaskExecute
r.execute(FinalizePropertiesTaskExecuter.java:46)
        at org.gradle.api.internal.tasks.execution.ResolveTaskExecutionModeExecu
ter.execute(ResolveTaskExecutionModeExecuter.java:62)
        at org.gradle.api.internal.tasks.execution.SkipTaskWithNoActionsExecuter
.execute(SkipTaskWithNoActionsExecuter.java:57)
        at org.gradle.api.internal.tasks.execution.SkipOnlyIfTaskExecuter.execut
e(SkipOnlyIfTaskExecuter.java:56)
        at org.gradle.api.internal.tasks.execution.CatchExceptionTaskExecuter.ex
ecute(CatchExceptionTaskExecuter.java:36)
        at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.exe
cuteTask(EventFiringTaskExecuter.java:77)
        at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.cal
l(EventFiringTaskExecuter.java:55)
        at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.cal
l(EventFiringTaskExecuter.java:52)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor$Callable
BuildOperationWorker.execute(DefaultBuildOperationExecutor.java:416)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor$Callable
BuildOperationWorker.execute(DefaultBuildOperationExecutor.java:406)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor$1.execut`

Is this issue related to internet?

raizoor commented 4 years ago
:jib (Thread[Execution worker for ':' Thread 2,5,main]) completed. Took 18 mins
38.51 secs.]

Was timeout ... Did you get this error on which version?

nithinkota commented 4 years ago

1.8.0

chanseokoh commented 4 years ago

18 minutes... that's a way long time to push. For me, pushing to Docker Hub takes only a few seconds. It looks like at some point something timed out and it led to Docker Hub not returning any HTTP response, hence "the target server failed to respond". So yes, a kind of a slow network issue. Is Docker Hub usually slow like this in your network? Does docker push take a lot of time too with Docker Hub in general?

At least it doesn't look like you have an auth issue anymore.

But FYI, using jib.to.auth.username|password should just work. That's an absolute last-resort solution that must just work. I've seen cases where a password contains special characters and some Jib users did not properly escape them when specifying the password string in build.gradle or on the command line. Maybe try this if you still have an auth issue: temporarily change your password to contain only letters and numbers, verify that you can do docker logout and docker login with the new password, and then test it with jib.to.auth.password again. It must work. If it fails, the only possible cause is that the username or password isn't correct.

nithinkota commented 4 years ago

@chanseokoh @raizoor

with docker push its taking <= 1 minute but with jib upto 77% uploading within 1 or 2 seconds from there onwards it will start uploading only 0.1% for every 10 to 15 seconds.After some time getting exception. My password is correct and it doesn't have any special characters.It's combination of alphabets and numbers.

chanseokoh commented 4 years ago

That's very interesting. We'd like to understand why it is slow with Jib.

Could you follow these instructions to capture low-level HTTP traffic and timing information? Also pass the --stacktrace, --debug, and --console=plain flags to Gradle to obtain debug output. So the command should look like

./gradlew \
    -Djava.util.logging.config.file=path/to/log.properties \
    -Djib.serialize=true \
    -Djib.console=plain \
    --console=plain --stacktrace --debug \
    jib

while you have created a separate file for path/to/log.properties. If all goes well, you should see logs like this. Verify that it contains lines like below.

CONFIG: -------------- REQUEST  --------------
GET https://registry-1.docker.io/v2/library/openjdk/blobs/sha256:1951f408509ba9ddcf240ef5d838c72c5596f97a05b063446508f2ba15d510f2

Then strip out any sensitive info and upload the file here (drag-and-drop a file into a GitHub comment input box).

nithinkota commented 4 years ago

@chanseokoh

Logs of a build which is currently in progress 1.8.0 version.Getting unauthorised

-------------- RESPONSE --------------
HTTP/1.1 202 Accepted
Content-Length: 0
Docker-Distribution-Api-Version: registry/2.0
Docker-Upload-Uuid: 76e46e51-9adb-4edb-850e-27f6a91e8801
Location: https://registry-1.docker.io/v2/nithin4325/demo/blobs/uploads/76e46e51
-9adb-4edb-850e-27f6a91e8801?_state=5zRHSFycZNYcyNTG6C134Nk38e5iHm87nEoDKECQQlV7
Ik5hbWUiOiJuaXRoaW40MzI1L2RlbW8iLCJVVUlEIjoiNzZlNDZlNTEtOWFkYi00ZWRiLTg1MGUtMjdm
NmE5MWU4ODAxIiwiT2Zmc2V0IjoxNTYwMzMxOCwiU3RhcnRlZEF0IjoiMjAyMC0wMS0wOFQxNTozMDoy
OFoifQ%3D%3D
Range: 0-15603317
Date: Wed, 08 Jan 2020 15:37:25 GMT
Strict-Transport-Security: max-age=31536000

-------------- REQUEST  --------------
PUT https://registry-1.docker.io/v2/nithin4325/demo/blobs/uploads/76e46e51-9adb-
4edb-850e-27f6a91e8801?_state=5zRHSFycZNYcyNTG6C134Nk38e5iHm87nEoDKECQQlV7Ik5hbW
UiOiJuaXRoaW40MzI1L2RlbW8iLCJVVUlEIjoiNzZlNDZlNTEtOWFkYi00ZWRiLTg1MGUtMjdmNmE5MW
U4ODAxIiwiT2Zmc2V0IjoxNTYwMzMxOCwiU3RhcnRlZEF0IjoiMjAyMC0wMS0wOFQxNTozMDoyOFoifQ
%3D%3D&digest=sha256:ed0a6a58b0d1f235e1d9015d264ebc743d000d8543df6c6661e0363dfd1
459b5
Accept:
Accept-Encoding: gzip
Authorization: <Not Logged>
User-Agent: jib 1.8.0 jib-gradle-plugin Google-HTTP-Java-Client/1.33.0 (gzip)

curl -v --compressed -X PUT -H 'Accept: ' -H 'Accept-Encoding: gzip' -H 'Authori
zation: <Not Logged>' -H 'User-Agent: jib 1.8.0 jib-gradle-plugin Google-HTTP-Ja
va-Client/1.33.0 (gzip)' -- 'https://registry-1.docker.io/v2/nithin4325/demo/blo
bs/uploads/76e46e51-9adb-4edb-850e-27f6a91e8801?_state=5zRHSFycZNYcyNTG6C134Nk38
e5iHm87nEoDKECQQlV7Ik5hbWUiOiJuaXRoaW40MzI1L2RlbW8iLCJVVUlEIjoiNzZlNDZlNTEtOWFkY
i00ZWRiLTg1MGUtMjdmNmE5MWU4ODAxIiwiT2Zmc2V0IjoxNTYwMzMxOCwiU3RhcnRlZEF0IjoiMjAyM
C0wMS0wOFQxNTozMDoyOFoifQ%3D%3D&digest=sha256:ed0a6a58b0d1f235e1d9015d264ebc743d
000d8543df6c6661e0363dfd1459b5'
-------------- RESPONSE --------------
HTTP/1.1 401 Unauthorized
Content-Type: application/json
Docker-Distribution-Api-Version: registry/2.0
Www-Authenticate: Bearer realm="https://auth.docker.io/token",service="registry.
docker.io",scope="repository:nithin4325/demo:pull,push",error="invalid_token"
Date: Wed, 08 Jan 2020 15:37:26 GMT
Content-Length: 232
Strict-Transport-Security: max-age=31536000

Total: 232 bytes
{"errors":[{"code":"UNAUTHORIZED","message":"authentication required","detail":[
Executing tasks:
[========================      ] 81.7% complete
> pushing blob sha256:2da0731fed5ed978622b602bf...

<=========----> 75% EXECUTING [13m 55s]
> :jib
chanseokoh commented 4 years ago

Thanks for the quick turnaround. That is revealing. I am suspecting something here. I'll take a look.

nithinkota commented 4 years ago

Logs from jenkins


Caused by: com.google.cloud.tools.jib.plugins.common.BuildStepsExecutionException: Build image failed, perhaps you should make sure your credentials for 'registry-1.docker.io/nithin4325/demo' are set up correctly. See https://github.com/GoogleContainerTools/jib/blob/master/docs/faq.md#what-should-i-do-when-the-registry-responds-with-unauthorized for help
    at com.google.cloud.tools.jib.plugins.common.JibBuildRunner.handleRegistryUnauthorizedException(JibBuildRunner.java:181)
    at com.google.cloud.tools.jib.plugins.common.JibBuildRunner.runBuild(JibBuildRunner.java:248)
    at com.google.cloud.tools.jib.gradle.BuildImageTask.buildImage(BuildImageTask.java:100)
    at org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:104)
    ... 186 more
Caused by: com.google.cloud.tools.jib.api.RegistryUnauthorizedException: Unauthorized for registry-1.docker.io/nithin4325/demo
    at com.google.cloud.tools.jib.registry.RegistryEndpointCaller.call(RegistryEndpointCaller.java:164)
    at com.google.cloud.tools.jib.registry.RegistryEndpointCaller.call(RegistryEndpointCaller.java:115)
    at com.google.cloud.tools.jib.registry.RegistryClient.callRegistryEndpoint(RegistryClient.java:473)
    at com.google.cloud.tools.jib.registry.RegistryClient.pushBlob(RegistryClient.java:422)
    at com.google.cloud.tools.jib.builder.steps.PushBlobStep.call(PushBlobStep.java:96)
    at com.google.cloud.tools.jib.builder.steps.PushLayerStep.call(PushLayerStep.java:94)
    at com.google.cloud.tools.jib.builder.steps.PushLayerStep.call(PushLayerStep.java:34)
    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)
Caused by: com.google.cloud.tools.jib.http.ResponseException: 401 Unauthorized
{"errors":[{"code":"UNAUTHORIZED","message":"authentication required","detail":[{"Type":"repository","Class":"","Name":"nithin4325/demo","Action":"pull"},{"Type":"repository","Class":"","Name":"nithin4325/demo","Action":"push"}]}]}

    at com.google.cloud.tools.jib.http.FailoverHttpClient.call(FailoverHttpClient.java:315)
    at com.google.cloud.tools.jib.http.FailoverHttpClient.call(FailoverHttpClient.java:237)
    at com.google.cloud.tools.jib.registry.RegistryEndpointCaller.call(RegistryEndpointCaller.java:139)
    ... 9 more
Caused by: com.google.api.client.http.HttpResponseException: 401 Unauthorized
{"errors":[{"code":"UNAUTHORIZED","message":"authentication required","detail":[{"Type":"repository","Class":"","Name":"nithin4325/demo","Action":"pull"},{"Type":"repository","Class":"","Name":"nithin4325/demo","Action":"push"}]}]}

    at com.google.api.client.http.HttpRequest.execute(HttpRequest.java:1097)
    at com.google.cloud.tools.jib.http.FailoverHttpClient.call(FailoverHttpClient.java:309)
    ... 11 more
chanseokoh commented 4 years ago

Nah, nothing seems wrong. Still looks normal. @nithinkota can you upload the entire log file?

And can't you try Jib locally on your laptop and not on Jenkins?

nithinkota commented 4 years ago

@chanseokoh I trying with that command but not logging to file.

chanseokoh commented 4 years ago

You should capture both stdout and stderr. On Linux, this can be done like this:

./gradlew ... jib > log.txt 2>&1

According to this doc, looks like this is same on Windows.

And don't forget to provide --console=plain. From the log above, it doesn't seem like you provided it.

nithinkota commented 4 years ago

@chanseokoh I used this command `gradlew -Djib.serialize=true -Djib.console=plain --console=plain --stacktrace --debug -Djib.console=plain jib > log.TXT 2>&1

Still it's building from past 10 mitues.Can I stop send that file?

`

nithinkota commented 4 years ago

@chanseokoh log.TXT

chanseokoh commented 4 years ago

@nithinkota sorry, you didn't provide -Djava.util.logging.config.file=path/to/log.properties (or the log.properties path is wrong).

But I already think the main trigger of the issue is your slow network interacting with Docker Hub. I see you have a BLOB of digest 2da0731fed5ed978622b602bfc9396352e3012c1f5228fa180bf2f105d226e1e whose size is about ~40MB.

2020-01-08T22:53:52.513+0530 [DEBUG] [org.gradle.api.Task] TIMING   Pushing BLOB digest: sha256:2da0731fed5ed978622b602bfc9396352e3012c1f5228fa180bf2f105d226e1e, size: 42567026

And I can see from your log that uploading 1K can take as much as a second. Also, I see that in a previous instance, BLOBs you wanted to upload were already on Docker Hub and therefore Jib was able to skip uploading those BLOBs. But this time no BLOBs were on the target Docker Hub, so I suppose you are cleaning the target repo to start from a clean state.

It'd be good to verify if the slow network is a triggering factor. Please carefully follow these instructions.

  1. First, do ./gradlew -Djib.to.image=nithin4325/demo jibDockerBuild to push to your local Docker daemon. Make sure that you see the following Gradle output:

    Containerizing application to Docker daemon as nithin4325/demo...

    and

    Built image to Docker daemon as nithin4325/demo

    Note the "to Docker daemon" string above.

  2. Verify that running docker images show

    $ docker images
    ...
    nithin4325/demo                       latest                     ...
    ...
  3. Now, run docker push nithin4325/demo. Verify that all the layers are uploaded.

  4. Now, without ever touching your project, run

    ./gradlew -Djava.util.logging.config.file=path/to/log.properties -Djib.serialize=true -Djib.console=plain --console=plain --stacktrace --debug -Djib.to.image=nithin4325/demo jib > log-after-docker-push.txt 2>&1

    Please make sure you run the exact command including -Djib.to.image=nithin4325/demo. Don't forget to update path/to/log.properties in the command above and place the file at the correct path.

  5. Verify log-after-docker-push.txt has lines like this:

    -------------- REQUEST  --------------
    PUT https://registry-1.docker.io/v2/nithin4325/demo/blobs/uploads/76e46e51-9adb-4edb-850e-27f6a91e8801?...
    Accept:
    Accept-Encoding: gzip
    Authorization: <Not Logged>
  6. Upload log-after-docker-push.txt.

nithinkota commented 4 years ago

@chanseokoh log-after-docker-push.txt

I followed steps exactly whatever you have provided. Those lines are not there.

chanseokoh commented 4 years ago

I believe this is a duplicate of #691. The triggering factor seems to be the slow network. It will become certain once I can see the low-level HTTP requests and responses, but #691 is the only logical explanation that fits into this log.

Those lines are not there.

You had those lines in https://github.com/GoogleContainerTools/jib/issues/2207#issuecomment-572128861, so something must have not been configured correctly. Particularly,

-Djava.util.logging.config.file=path/to/log.properties

path/to/log.properties should point to the right file that's readable with the right contents. I know you did it in https://github.com/GoogleContainerTools/jib/issues/2207#issuecomment-572128861, so you can make it work.

But in any case, I believe the issue is #691. I'll close this as a dup. Please follow #691.

chanseokoh commented 4 years ago

To add, regarding auth, Jib was able to retrieve your login credentials (possibly from ~/.docker/config.json) and it looks to me that Jib successfully authenticated with Docker Hub. But it is probably that the token returned from Docker Hub after successful authentication is expired during the operation.

nithinkota commented 4 years ago

@chanseokoh

Today again I tried with this issue and internet speed is 54Mbps. With docker push it took 2 minutes to upload to docker hub.After uploading again I pushed it took only 2 to 3 seconds. with jib again I got same exception.So I tried the command what you gave by configuring the path of log.properties which is present in my application.

gradlew -Djava.util.logging.config.file=D:/demo/src/main/resources/log.properties -Djib.serialize=true -Djib.console=plain --console=plain --stacktrace --debug -Djib.to.image=nithin4325/demo jib > log-after-docker-push.txt 2>&1 When I verify the file following lines are present

2020-01-10T15:46:45.564+0530 [INFO] [com.google.api.client.http.HttpTransport] -------------- REQUEST  --------------
HEAD https://registry-1.docker.io/v2/nithin4325/demo/blobs/sha256:9ff2acc3204b4093126adab3fed72de8f7bbfe332255b199c30b8b185fcf6923
Accept: ``
Accept-Encoding: gzip
Authorization: <Not Logged>
User-Agent: jib 1.8.0 jib-gradle-plugin Google-HTTP-Java-Client/1.33.0 (gzip)

But I executed same command 4 times only for the first time generated file having these lines. From second generated files does not have these lines. I got doubt Is this issue related to network? Why because I have tried more than 5 different networks having more than 50Mbps speed.

log-after-docker-push.txt is the file having those lines.

log-after-docker-push.txt log-after-docker-push1.txt log-after-docker-push2.txt

`

chanseokoh commented 4 years ago

Your log shows that authenticating to Docker Hub took more than 8 seconds.

20-01-10T16:51:28.830+0530 [DEBUG] [org.gradle.api.Task] TIMED    Authenticating push to registry-1.docker.io : 8267.0 ms

It should normally take a fraction of a second. On my machine:

[DEBUG] TIMED   Authenticating push to registry-1.docker.io : 620.0 ms

Your network may be fast in general. But accessing Docker Hub from your network is very slow.

Don't worry. I think your issue is really a duplicate #691, and I'm working on fixing #691 as a priority.

chanseokoh commented 4 years ago

Just in case, can you also try this on a beefy/powerful machine? Just trying to rule out the possibility that this is due to some resources constrained on your machine.

nithinkota commented 4 years ago

@chanseokoh Thank you so much.Please tell me once it is done.I will try to do this in another machine.

chanseokoh commented 4 years ago

I'll update here once it's fixed.

And about not getting network traffic logs sometimes, I just remembered this comment. I should have recalled this weird behavior on Gradle, my bad.

nithinkota commented 4 years ago

@chanseokoh Today I tried in Linux Ec2 instance image was uploaded to docker hub with 12 to 14 seconds.Is this issue related to my machine or all windows machines only like this?

chanseokoh commented 4 years ago

I think the slow connection problem with Docker Hub is unique to your machine. Can you try some other machines within your network? And also your machine on a different network? Trying to see if it is primarily your network or your machine.

nithinkota commented 4 years ago

@chanseokoh Thank you so much for reply. Just now I tried by upgrading to version 2.0.0. Image uploaded to hub successfully but it took 33 minutes. I am attaching log file. I will try in different machine and update you. log-after-docker-push.txt

chanseokoh commented 4 years ago

Cool.

Image uploaded to hub successfully but it took 33 minutes

I noticed the 33-minute build was for taking a log file when you used -Djib.serialize=true. Note that I requested setting -Djib.serialize=true to capture serialized logs, but setting this flag makes Jib run using a single thread. Taking the flag out will enable concurrent upload and download, so I think that'll make it a little bit faster. However, I still see from your log that communication with Docker Hub on your machine is fairly slow:

2020-01-29T23:25:25.588+0530 [DEBUG] [org.gradle.api.Task] TIMED    Authenticating push to registry-1.docker.io : 4867.0 ms

Other than that, nothing seems wrong. It will be interesting to know if it is mainly your network or your machine that is accountable for the slow connection to Docker Hub. I'll think of something in the meantime.

nithinkota commented 4 years ago

@chanseokoh I gave -Djib.serialize=true in command

gradlew -Djava.util.logging.config.file=D:/demo/src/main/resources/log.properties -Djib.serialize=true -Djib.console=plain --console=plain --stacktrace --debug -Djib.to.image=nithin4325/demo jib > log-after-docker-push.txt 2>&1

chanseokoh commented 4 years ago

Yeah, I mean, for taking a log file, it helps to give -Djib.serialize=true, which makes us easy to understand serialized network communications in the log. I was just saying, for normal usage, you don't want to give -Djib.serialize=true because it will make Jib significantly slower.

chanseokoh commented 4 years ago

I have written a tiny Java program that uploads random 40MB to Docker Hub. Could you test this out on your machine?

  1. Clone this repo:
    $ git clone https://github.com/chanseokoh/docker-hub-upload-speed-test.git
    $ cd docker-hub-upload-speed-test
  2. Open GoogleHttpClientMain.java and set the correct password for your Docker Hub account nithin4325.
    String username = "nithin4325";
    String password = YOUR PASSWORD    <---- UPDATE THIS
    String dockerHubRepo = "nithin4325/demo";
  3. Compile first.
    $ mvn compile
  4. Run.
    $ mvn exec:java

If all goes well, it should authenticate with Docker Hub and time uploading 40MB. On my machine, it takes 2.3 seconds.

requesting bearer auth token from Docker Hub...
get upload URL...
start timing uploading 40MB to Docker Hub...
elapsed (s): 2.3

Can you try this on your machine?

nithinkota commented 4 years ago

@chanseokoh Build took almost 10 minutes.

start timing uploading 40MB to Docker Hub...
elapsed (s): 585.6
[INFO] BUILD SUCCESS
[INFO] Total time:  09:56 min
chanseokoh commented 4 years ago

Alright, just as I anticipated.

One more test, and I think we're basically done. I've updated the tiny test program, so let's do this for the last time.

  1. Go to the repo and pull the master branch.
    $ cd docker-hub-upload-speed-test
    $ git pull  # make sure you sync with master

    If you happened to delete the repo you previously checked out, then just clone a fresh new one.

    $ git clone https://github.com/chanseokoh/docker-hub-upload-speed-test.git
    $ cd docker-hub-upload-speed-test
  2. Update ApacheHttpClientMain.java and set your Docker Hub password.
  3. Compile first.
    $ mvn compile 
  4. Run.
    $ mvn exec:java -Dexec.mainClass=ApacheHttpClientMain