Fork me on GitHub
#docker
<
2020-01-28
>
mkvlr04:01:42

@rahul080327 sorry for the long silence, I’m struggling to find the time to try this out right now but I now asked my colleague to give it a try and will let you know. Our hope is to switch nextjournal over from spotify-docker eventually…

lispyclouds06:01:53

@christian.paling maybe lein deps :plugin-tree would solve this. And the docker thing can be separated out a bit by having multistage docker files wherein you just copy the uber jar into a plain open jdk image with a lot less size 🙂 I think not having the sources and the huge ~/.m2 dir into your deployment artifact is cleaner

lispyclouds06:01:42

@mkvlr awesome! lemme know what can be improved!

mkvlr18:01:11

@rahul080327 one thing that I noticed: there’s no support for checkpoint, yet, correct? https://docs.docker.com/engine/reference/commandline/checkpoint/ This is currently an experimental feature in docker (but we’re using it). Is there an easy way to include it? I see it’s not in https://github.com/lispyclouds/clj-docker-client/blob/master/resources/api/v1.40.yaml

lispyclouds20:01:42

@mkvlr okay so this is interesting as from my searches I dont think this a properly exposed API. (i may be wrong). Couldn't find it in any of the API clients too. From really deep searching in the docker daemon source I see this: https://github.com/moby/moby/pull/22049/files#diff-8038ade87553e3a654366edca850f83dR11

lispyclouds20:01:17

looks like this has been implemented for a while but somehow not exposed?

lispyclouds20:01:23

I tried CURLing the endpoints with curl --unix-socket /var/run/docker.sock "" and it is answering! 😮

lispyclouds20:01:57

since this is not in the swagger spec, you can try to use the low-level functions in the client though

lispyclouds20:01:02

(req/fetch {:conn (connect {:uri "unix:///var/run/docker.sock"})
            :url  "/containers/conny/checkpoints"})

lispyclouds20:01:34

needs a (require '[clj-docker-client.requests :as req])

lispyclouds20:01:43

this should technically work i think. but you need to parse the (JSON?) responses manually.

lispyclouds20:01:23

i really think the client should stick to published APIs, but what are your thoughts @mkvlr?

lispyclouds20:01:14

apologies as I haven't really used checkpoints before 😕

mkvlr20:01:58

@rahul080327 awesome thanks! I also don’t really understand why it’s not in the swagger api file. Do you know of a way to regenerate this with experimental flags enabled?

mkvlr20:01:57

it does exist in the docker command line api…

lispyclouds20:01:59

i really tried hard to find it, but i think this needs source compilation?

mkvlr20:01:40

ah right, that would be ideal

lispyclouds20:01:17

I will try to find out more, but is this a good place for you to start?

mkvlr20:01:43

yes, for sure!

mkvlr20:01:59

docker + swagger is pretty much ungooglable

lispyclouds20:01:20

yeah its totally what we are not looking for

lispyclouds20:01:48

any leads on how to make this lib more flexible is much appreciated too!

lispyclouds20:01:04

the fact that this is un documented and none of the other clients support is is super weird

mkvlr20:01:12

> If you omit the version-prefix, the current version of the API (v1.40) is used. For example, calling `/info` is the same as calling `/v1.40/info`. Using the API without a version-prefix is deprecated and will be removed in a future release.

mkvlr20:01:22

what’s being served on /info?

lispyclouds20:01:46

this returns a map of the system info

mkvlr20:01:04

ok, not what we’re looking for

lispyclouds20:01:36

I'm looking at the source of the docker cli to see how its doing it

lispyclouds20:01:49

looks like it, i at least couldnt find a way to generate it without source compilation. but again, i could be wrong

lispyclouds20:01:07

otherwise why would it have so many contributors i guess?

mkvlr20:01:13

gotta go for lunch, bbl

mkvlr20:01:21

yes, looks like it’s manual

lispyclouds20:01:47

fun discussion. lemme know if you find anything

lispyclouds20:01:08

also when would be a good time to release too 🙂