Running Torus inside docker container

[collingo]

I'm trying to torus run inside a Docker container. Confusingly it has worked once and otherwise failed without any changes to the code/setup. The error I get back changes between runs too so I suspect there might be a race condition.

The error tends to be one of the following... (the first is the most common)

Attempting to login with token id: [machine-token-id]
Error fetching secrets.
Get http://localhost/v1/credentials?path=[url-escaped-secret-path]: EOF

Attempting to login with token id: [machine-token-id]
Get http://localhost/v1/self: read unix @->/root/.torus/daemon.socket: read: connection reset by peer

Attempting to login with token id: [machine-token-id]
Could not log in
Post http://localhost/v1/login: EOF
You must be logged in to run 'run'.
Login using 'login' or create an account using 'signup'.

Have I installed Torus into the container correctly? The Dockerfile I'm using looks something like this...

FROM node:6.10.0-alpine
RUN mkdir -p /usr/src
WORKDIR /usr/src
COPY src /usr/src
RUN apk add --no-cache --virtual .gyp python make g++ \
  && npm i -g torus-cli \
  && apk del .gyp
RUN npm i
EXPOSE 80
CMD torus run -o [org-name] -p [project-name] -e [env-name] -- node .

...and the docker run command looks something like this...

docker run --rm -it \
  -p 0.0.0.0:70:80 \
  -e 'TORUS_TOKEN_ID=[machine-token-id]' \
  -e 'TORUS_TOKEN_SECRET=[machine-token-secret]' \
  [image-name]

Do you expect torus run should work in a containerised environment? Looking at the docs it seems torus machines are ideal for this use case.

torus -v

CLI         0.24.1
Daemon      0.24.1
Registry    0.20.0

torus debug

Unauthorized: invalid login

~/.torus/daemon.logs

2017/06/09 10:41:27 v0.24.1 of the Daemon is now listening on /root/.torus/daemon.socket
2017/06/09 10:41:27 last update check: 0001-01-01 00:00:00 +0000 UTC
2017/06/09 10:41:27 GET /v1/version
2017/06/09 10:41:27 GET /v1/session
2017/06/09 10:41:28 POST /v1/login
2017/06/09 10:41:28 GET /v1/self
2017/06/09 10:41:28 check updates
2017/06/09 10:42:44 v0.24.1 of the Daemon is now listening on /root/.torus/daemon.socket
2017/06/09 10:42:44 cannot get last update: parsing time "" as "2006-01-02T15:04:05Z07:00": cannot parse "" as "2006"
2017/06/09 10:42:44 last update check: 0001-01-01 00:00:00 +0000 UTC
2017/06/09 10:42:44 GET /v1/version
2017/06/09 10:42:44 GET /v1/version
2017/06/09 10:42:44 GET /proxy/version
2017/06/09 10:42:44 GET /v1/updates
2017/06/09 10:42:45 check updates
2017/06/09 10:43:31 v0.24.1 of the Daemon is now listening on /root/.torus/daemon.socket
2017/06/09 10:43:31 cannot get last update: parsing time "" as "2006-01-02T15:04:05Z07:00": cannot parse "" as "2006"
2017/06/09 10:43:31 last update check: 0001-01-01 00:00:00 +0000 UTC
2017/06/09 10:43:31 GET /v1/version
2017/06/09 10:43:32 GET /v1/self
2017/06/09 10:43:33 check updates

[ianlivingstone]

It looks like the Torus daemon is stopping and starting, losing the login session. Is it possible that the daemon and cli versions don't line up?

Relevant Issue: #257

[collingo]

Thanks for this @ianlivingstone, I checked the CLI and daemon versions and they were both at 0.24.1.

I have found a temporary solution however. I was using the compact Alpine linux distro as my base image. When switching to the non-Alpine image (Ubuntu I think) it seems to run the daemon just fine.

This change has increased the image size by 500% so it's not ideal. The image readme suggests the following which may be relevant...

The main caveat to note is that it does use musl libc instead of glibc and friends, so certain software might run into issues depending on the depth of their libc requirements.

Does torus depend on "glibc and friends" or is there a way to get it working using musl libc?

[jbowes]

Does torus depend on "glibc and friends" or is there a way to get it working using musl libc?

Nope! but in this case, it does need system ca certificates, which is why it was failing for you. A quick workaround would be to apk add --no-cache ca-certificates before running.

There are two bugs here though that should be fixed:

• When checking for updates, the client attempts to use the http response before seeing if there is an error: https://github.com/manifoldco/torus-cli/blob/master/daemon/updates/updates.go#L236
• The updates check call uses the default http client, rather than using one that uses the included CA certificate bundle

[collingo]

Thanks @jbowes - sadly adding ca-certificates didn't seem to help. I'm going to stick with the Ubuntu base image for now and just bite the bullet on the extra memory/storage requirements. Cheers for your help