freshen docker images on aptdocker.azureedge.net #1914
Comments
|
I would like to start contributing. Can I take this issue? |
|
Hi @MorrisLaw ! We currently use |
|
These are the available docker-engine images on a cluster host: Compare CE images to published versions here: |
|
Thank you for the response @jackfrancis , I'll start working on this. |
|
Thanks @MorrisLaw ! |
|
Per #2876 it sounds like we may be moving over to containerd, but it would still be good to see the mirror we use here and valid versions be updated to the latest apt repository for those who want to use (or try to use) the latest version of docker as the engine. Our default 1.13.x version of docker runtime is ancient 2017-02-08 and contains countless security and bug fixes :( |
|
I agree with @dtzar, I think we should still be able to use a newer version of docker if its supported by kubernetes. We could use a different mirror right now, but the validation breaks our ability to use that version. You'll have to excuse my ignorance a little, I haven't read enough about containerd yet to know whether it is a sufficient drop-in replacement to docker for our needs. |
|
https://stackoverflow.com/questions/46649592/dockerd-vs-docker-containerd-vs-docker-runc-vs-docker-containerd-ctr-vs-docker-c seems to suggest containerd does listen on a unix socket, but can docker client inside a container use a volume mounted containerd socket of the host? I'm guessing the interfaces are a bit different? Might be able to work around it using a dind docker image to run make tasks inside the vsts-agent container, but thats a bit nesty. Edit - actually no that wont work as the build tools I need wont be in the dind image .. duh :( This leads me to ask if you would consider leaving the docker option in for future updates, otherwise I fear it may box us into a corner. |
no since docker is not there it will not, but you can use the docker:dind containers on docker hub, which is actually a better idea than mounting the host socket anyways |
|
why not do a |
|
@jessfraz thanks, yeah was thinking the same just now. I will give that a shot. |
|
there are lots of solutions here... you can run docker:dind and share the network namespace with a different container with your build tools and just use the docker daemon in the other container.... you do not need a omnolithic container with your tools either i see many possible solutions:
|
|
@jessfraz will docker client in the vsts-agent container work with a containerd socket to be able to start the docker:dind image? Or would I base the vsts-agent on docker:dind? |
|
what I would do is in that pod with the vsts agent have another container that is running docker:dind, then in the vsts-agent container if you are shelling out to docker you need the docker tool in there if you are using an api client library you do not... here is an example... https://github.com/genuinetools/contained.af/blob/master/Makefile#L149 |
|
dont worry about the containerd socket you do not need it, you just need a dind container... |
|
the dind container just runs the docker daemon... so you can use any client in another container to communicate with the daemon (containerd not involved at all.) |
|
@jessfraz ah .. I only ask as we're helm deploying the vsts-agent with /var/run/docker.sock mounted into the vsts-agent (so its really more like docker on docker than in it) : https://github.com/Azure/helm-vsts-agent/blob/master/templates/vsts-agent.yaml#L53-L56 |
|
well its docker running a nested docker, thats where the name comes from, mounting the socket is actually known as a "bind mount" not docker-in-docker |
|
and yeah... that really should not have ever been mounting the host socket...... |
|
thanks for the feedback :) I'll fix the vsts-agent image and try again with dind. |
|
@jessfraz this almost works now. I removed the socket bind mount from the helm vsts-agent deployment, and added a dind container in the same pod as the vsts-agent. It almost works, but fails to TLS handshake on a nuget.org url when doing a 'dotnet restore' in a dind based build container. I have a feeling it might be MTU related. Different problem now I know, but would be interested to see if anyone else has a similar problem using dind in this way. Heres one: |
|
you might need ca-certs?
…On Thu, Jun 21, 2018 at 5:25 PM Ryan Grenz ***@***.***> wrote:
@jessfraz <https://github.com/jessfraz> this almost works now. I removed
the socket bind mount from the helm vsts-agent deployment, and added a dind
container in the same pod as the vsts-agent.
It almost works, but fails to TLS handshake on a nuget.org url when doing
a 'dotnet restore' in a dind based build container. I have a feeling it
might be MTU related.
curl -v -I https://api.nuget.org/v3/index.json
* Trying 152.199.19.160...
* TCP_NODELAY set
* Connected to api.nuget.org (152.199.19.160) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ***@***.***
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* Unknown SSL protocol error in connection to api.nuget.org:443
* Curl_http_done: called premature == 1
* stopped the pause stream!
* Closing connection 0
curl: (35) Unknown SSL protocol error in connection to api.nuget.org:443
Different problem now I know, but would be interested to see if anyone
else has a similar problem using dind in this way.
Heres one:
https://stackoverflow.com/questions/38882113/docker-in-docker-ssl-problems?rq=1
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1914 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABYNbME_bsjEhN7iiJg3Rbz_NX709Rrhks5t_A9igaJpZM4Q-IdZ>
.
--
Jessie Frazelle
4096R / D4C4 DD60 0D66 F65A 8EFC 511E 18F3 685C 0022 BFF3
pgp.mit.edu <http://pgp.mit.edu/pks/lookup?op=get&search=0x18F3685C0022BFF3>
|
|
oh i guess the certs are there
…On Thu, Jun 21, 2018 at 5:28 PM Jessie Frazelle ***@***.***> wrote:
you might need ca-certs?
On Thu, Jun 21, 2018 at 5:25 PM Ryan Grenz ***@***.***>
wrote:
> @jessfraz <https://github.com/jessfraz> this almost works now. I removed
> the socket bind mount from the helm vsts-agent deployment, and added a dind
> container in the same pod as the vsts-agent.
>
> It almost works, but fails to TLS handshake on a nuget.org url when
> doing a 'dotnet restore' in a dind based build container. I have a feeling
> it might be MTU related.
>
> curl -v -I https://api.nuget.org/v3/index.json
> * Trying 152.199.19.160...
> * TCP_NODELAY set
> * Connected to api.nuget.org (152.199.19.160) port 443 (#0)
> * ALPN, offering h2
> * ALPN, offering http/1.1
> * Cipher selection: ***@***.***
> * successfully set certificate verify locations:
> * CAfile: /etc/ssl/certs/ca-certificates.crt
> CApath: /etc/ssl/certs
> * TLSv1.2 (OUT), TLS header, Certificate Status (22):
> * TLSv1.2 (OUT), TLS handshake, Client hello (1):
> * Unknown SSL protocol error in connection to api.nuget.org:443
> * Curl_http_done: called premature == 1
> * stopped the pause stream!
> * Closing connection 0
> curl: (35) Unknown SSL protocol error in connection to api.nuget.org:443
>
> Different problem now I know, but would be interested to see if anyone
> else has a similar problem using dind in this way.
>
> Heres one:
>
> https://stackoverflow.com/questions/38882113/docker-in-docker-ssl-problems?rq=1
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#1914 (comment)>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/ABYNbME_bsjEhN7iiJg3Rbz_NX709Rrhks5t_A9igaJpZM4Q-IdZ>
> .
>
--
Jessie Frazelle
4096R / D4C4 DD60 0D66 F65A 8EFC 511E 18F3 685C 0022 BFF3
pgp.mit.edu
<http://pgp.mit.edu/pks/lookup?op=get&search=0x18F3685C0022BFF3>
--
Jessie Frazelle
4096R / D4C4 DD60 0D66 F65A 8EFC 511E 18F3 685C 0022 BFF3
pgp.mit.edu <http://pgp.mit.edu/pks/lookup?op=get&search=0x18F3685C0022BFF3>
|
|
like this doesnt seem like a "docker problem" its a this version of ssl or
whatever in the container is not working w nuget
On Thu, Jun 21, 2018 at 5:28 PM Jess Frazelle <[email protected]>
wrote:
… you might need ca-certs?
On Thu, Jun 21, 2018 at 5:25 PM Ryan Grenz ***@***.***>
wrote:
> @jessfraz <https://github.com/jessfraz> this almost works now. I removed
> the socket bind mount from the helm vsts-agent deployment, and added a
dind
> container in the same pod as the vsts-agent.
>
> It almost works, but fails to TLS handshake on a nuget.org url when
doing
> a 'dotnet restore' in a dind based build container. I have a feeling it
> might be MTU related.
>
> curl -v -I https://api.nuget.org/v3/index.json
> * Trying 152.199.19.160...
> * TCP_NODELAY set
> * Connected to api.nuget.org (152.199.19.160) port 443 (#0)
> * ALPN, offering h2
> * ALPN, offering http/1.1
> * Cipher selection:
***@***.***
> * successfully set certificate verify locations:
> * CAfile: /etc/ssl/certs/ca-certificates.crt
> CApath: /etc/ssl/certs
> * TLSv1.2 (OUT), TLS header, Certificate Status (22):
> * TLSv1.2 (OUT), TLS handshake, Client hello (1):
> * Unknown SSL protocol error in connection to api.nuget.org:443
> * Curl_http_done: called premature == 1
> * stopped the pause stream!
> * Closing connection 0
> curl: (35) Unknown SSL protocol error in connection to api.nuget.org:443
>
> Different problem now I know, but would be interested to see if anyone
> else has a similar problem using dind in this way.
>
> Heres one:
>
>
https://stackoverflow.com/questions/38882113/docker-in-docker-ssl-problems?rq=1
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#1914 (comment)
>,
> or mute the thread
> <
https://github.com/notifications/unsubscribe-auth/ABYNbME_bsjEhN7iiJg3Rbz_NX709Rrhks5t_A9igaJpZM4Q-IdZ
>
> .
>
--
Jessie Frazelle
4096R / D4C4 DD60 0D66 F65A 8EFC 511E 18F3 685C 0022 BFF3
pgp.mit.edu <
http://pgp.mit.edu/pks/lookup?op=get&search=0x18F3685C0022BFF3>
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#1914 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABYNbGpO7HN85oFUZ8nPoMwOj3EKAtalks5t_A__gaJpZM4Q-IdZ>
.
--
Jessie Frazelle
4096R / D4C4 DD60 0D66 F65A 8EFC 511E 18F3 685C 0022 BFF3
pgp.mit.edu <http://pgp.mit.edu/pks/lookup?op=get&search=0x18F3685C0022BFF3>
|
|
It might not be a docker problem, but I can use the same image to build locally and I don't hit the nuget problem when doing a I only mention it here as this may be dind related, and others who follow this ticket and are trying the dind approach out might see similar problems: pypi/warehouse#4069 I've tried the libressl suggestion in the ticket though but it didn't seem to make any difference. |
|
For what its worth I fixed my issue. It was MTU related. I had to change dockerd's --mtu to 1450 in the dind image which adjusted it for me inside my build container. |
|
if anyone is interested, I have a PR open to the helm-vsts-agent repo to handle additional containers, volumes and env vars, so that I can neatly add a DIND sidecar to the vsts-agent deployment: Azure/helm-vsts-agent#7 |
|
@grenzr, I am running into a similar issue when trying to use docker-dind (running under k8s) to create ML model images, for the Acumos AI project (an LF project). The issue seems similar, as our Java components that use the docker-dind service to build images are logging build event sequences that are quite unusual, and lead up to the error below as reported by docker-dind:
"35" is an SSL error. This error does not occur when our platform is deployed using a host-based docker-engine, or when docker-dind is used in a bare-metal k8s cluster. Just in Azure. I need to find a workaround for this, so I am interested in trying out your MTU approach. Can you explain how you "change dockerd's --mtu to 1450 in the dind image"? |
|
@blsaws yes its an annoying problem that took me a little while to work out!
|
No description provided.
The text was updated successfully, but these errors were encountered: