Closed nithinkota closed 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.
I am new to docker.I started learning.This is my first project with spring boot docker. I need to give it as latest?
@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
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.
@raizoor I am able to push the image without jib.While push the image with jib getting exception.
@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.`
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
@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.
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.
@chanseokoh
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
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"
}
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.
@chanseokoh After adding helpers Image built successfully but not pushed to docker hub. jib version:1.4.0
Using Jib 1.8.0, can you upload the Gradle build log when running with the --stacktrace --info
parameters?
@nithinkota
gradle jibDockerBuild don't send your image to registry. It's like you builds locally.
@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
JIB 1.4.0 it's not good version to use, exactly for problems by auth. Try 1.6.1 or last.
I'll reopen this issue since the problem doesn't seem to be resolved yet.
@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?
: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?
1.8.0
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.
@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.
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).
@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
Thanks for the quick turnaround. That is revealing. I am suspecting something here. I'll take a look.
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
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?
@chanseokoh I trying with that command but not logging to file.
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.
@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?
`
@chanseokoh log.TXT
@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.
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.
Verify that running docker images
show
$ docker images
...
nithin4325/demo latest ...
...
Now, run docker push nithin4325/demo
. Verify that all the layers are uploaded.
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.
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>
Upload log-after-docker-push.txt
.
@chanseokoh log-after-docker-push.txt
I followed steps exactly whatever you have provided. Those lines are not there.
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.
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.
@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
`
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.
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.
@chanseokoh Thank you so much.Please tell me once it is done.I will try to do this in another machine.
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.
@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?
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.
@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
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.
@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
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.
I have written a tiny Java program that uploads random 40MB to Docker Hub. Could you test this out on your machine?
$ git clone https://github.com/chanseokoh/docker-hub-upload-speed-test.git
$ cd docker-hub-upload-speed-test
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";
$ mvn compile
$ 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?
@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
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.
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
ApacheHttpClientMain.java
and set your Docker Hub password.$ mvn compile
$ mvn exec:java -Dexec.mainClass=ApacheHttpClientMain
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 commandgradlew jib --image=demo:0.0.1-SNAPSHOT
.I am getting error