Docker container not building in ResinIO image


#1

I developed a docker file and was able to deploy it on a RPi 3 on the ResinOS image from resinos.io. When I wanted to test out the fleet management features on ResinIO, I used the OS image from the the site to burn an SD card for the Pi. Using the Resin CLI, the container build fails with the OS linked to my app on ResinIO.

Here is an output of the error from Resin

Step 1/16 : FROM resin/rpi-raspbian:jessie
jessie: Pulling from resin/rpi-raspbian
675864ba0040: Pull complete 7bf3f2fb6095: Pull complete 3fd1f6eb7320: Pull complete aa27f50daaae: Pull complete c8a7be5ebe5f: Pull complete 394899c2bf9d: Pull complete bb1073a7468e: Pull complete d49a5a1e2ebf: Pull complete 995fe058036a: Pull complete 3c0ddf3c9e2b: Pull complete ---> 5fea260b13c0 Step 2/16 : RUN apt-get -y update ---> Running in 5c6f703c3170 Get:1 http://archive.raspberrypi.org jessie InRelease [22.9 kB] Get:2 http://archive.raspbian.org jessie InRelease [14.9 kB] Get:3 http://archive.raspberrypi.org jessie/main armhf Packages [169 kB] Get:4 http://archive.raspbian.org jessie/main armhf Packages [13.3 MB] Get:5 http://archive.raspbian.org jessie/contrib armhf Packages [49.5 kB] Get:6 http://archive.raspbian.org jessie/non-free armhf Packages [101 kB] Get:7 http://archive.raspbian.org jessie/rpi armhf Packages [1297 B] Get:8 http://archive.raspbian.org jessie/firmware armhf Packages [1202 B] rdt push failed. Error: The command '/bin/sh -c apt-get -y update' returned a non-zero code: 137 Error: The command '/bin/sh -c apt-get -y update' returned a non-zero code: 137 at Stream.<anonymous> (/usr/local/lib/node_modules/resin-cli/node_modules/resin-sync/build/docker-utils.js:145:23) at emitOne (events.js:96:13) at Stream.emit (events.js:188:7) at drain (/usr/local/lib/node_modules/resin-cli/node_modules/through/index.js:36:16) at Stream.stream.queue.stream.push (/usr/local/lib/node_modules/resin-cli/node_modules/through/index.js:45:5) at Parser.parser.onToken (/usr/local/lib/node_modules/resin-cli/node_modules/resin-sync/node_modules/JSONStream/index.js:132:18) at Parser.proto.write (/usr/local/lib/node_modules/resin-cli/node_modules/resin-sync/node_modules/jsonparse/jsonparse.js:135:34) at Stream.<anonymous> (/usr/local/lib/node_modules/resin-cli/node_modules/resin-sync/node_modules/JSONStream/index.js:23:12) at Stream.stream.write (/usr/local/lib/node_modules/resin-cli/node_modules/through/index.js:26:11) at IncomingMessage.ondata (_stream_readable.js:555:20) at emitOne (events.js:96:13) at IncomingMessage.emit (events.js:188:7) at readableAddChunk (_stream_readable.js:176:18) at IncomingMessage.Readable.push (_stream_readable.js:134:10) at HTTPParser.parserOnBody (_http_common.js:123:22) at Socket.socketOnData (_http_client.js:362:20) at emitOne (events.js:96:13) at Socket.emit (events.js:188:7) at readableAddChunk (_stream_readable.js:176:18) at Socket.Readable.push (_stream_readable.js:134:10) at TCP.onread (net.js:547:20)

Here is the Dockerfile I’m using:

FROM resin/rpi-raspbian:jessie

WORKDIR /usr/src/app

RUN apt-get -y update
RUN apt-get install iputils-ping
RUN curl -sL https://deb.nodesource.com/setup_4.x | sudo -E bash -
RUN apt-get install -y nodejs

RUN npm install -g npm@3.10.9

COPY package.json package.json

RUN apt-get update && apt-get -yq install \
    htop \ 
    git \
    virt-what \
    libsodium-dev \
    libtool \
    build-essential \
    libkrb5-dev \
    automake \
    autoconf \
    lsof \
    rsync\
    ecryptfs-utils \
    keyutils \
    mercurial \
    python-dev \
    python-setuptools \
    libyaml-dev \
    libssl-dev \
    swig \
    python-pip \
    ntfs-3g \
    samba samba-common-bin

RUN git clone https://github.com/thomasmacpherson/piface.git  
RUN cd ./piface/c/ && ./autogen.sh && ./configure && make && make install && ldconfig

ADD . .
RUN npm install 
EXPOSE 80
CMD ["node", "main.js"] 

Any help will be greatly appreciated


#2

This is not the cause of your problem, but I think you should make far less “RUN”, because Docker creates one layer per RUN. Moreover, in older kernel versions (currently in use by ResinOS), you may not override permissions and file ownership set in a previous layer.

Just use “” like you do in “apt-get install” and if you have logical blocks, you can still introduce new lines and “#” comments to separate them.


#3

It doesn’t appear like I’m changing file permissions. The issue occurs when I use the CLI to deploy locally and on the first RUN command, regardless of what the RUN is supposed to accomplish


#4

Hey @d.imade, what exact command are you running? And what version of resinOS do you have on the device? We are trying to replicate this.


#5

This is the version of resinOS that’s on the device: Resin OS 2.0.8+rev1 (dev) from resinIO
This is the command i’m trying to run from the CLI:
sudo resin local push -s .
I then select the device I’m trying to build the container on, causing the failure in my original post.


#6

Thanks, I think we can reproduce this, so looking at more closely what’s happening.


#8

Hey @d.imade it turns out to be a known issue… It comes back to that if the user application does not have a commit pushed, then the supervisor running on the device is not put into local mode correctly, and thus it just cleans up the images while local push is building (as it does in “managed mode”)…

The current workaround is to push just any code (that builds correctly) to the application first. For example this this “dummy” project:

Afterwards you can work in local mode totally fine. When you switch from Local Mode back to managed, just push your application with a --force option for the first time. Or… you can just push your project’s current state to the application if it builds, then no need for the force push later when you switch back. Hope it makes sense!

We are working on fixing this, likely happening at the next milestone, as it seems like where we are heading with the supervisor and multicontainer support, it will be much simpler to get the correct behaviour. Sorry about the inconvenience in the meantime!


#9

Thanks for the information. I tried building the project that you referred to, but ended up getting this error message:

Step 1/2 : FROM resin/raspberry-pi-alpine
latest: Pulling from resin/raspberry-pi-alpine
96598928ae71: Pull complete
68130efce6c1: Pull complete
1b8839e961e1: Pull complete
50dc88138594: Pull complete
90db09913782: Pull complete
feb44abcf31a: Pull complete
7b33a93723b2: Pull complete
ea239b4cda4f: Pull complete
d3a7efeb4244: Pull complete
00dab88cc709: Pull complete
80d558d3fbdf: Pull complete
79512ef759c9: Pull complete
 ---> ed27aef1bd41
Step 2/2 : CMD while : ; do echo "Idling..."; sleep ${INTERVAL=600}; done
 ---> Running in 198d733ea280
 ---> 2374245e7118
Removing intermediate container 198d733ea280
Successfully built 2374245e7118
- Creating 'idling' container
- Starting 'idling' container
rdt push failed. Error: Error while starting container idling: Error: (HTTP code 400) unexpected - starting container with non-empty request body was deprecated since v1.10 and removed in v1.12  Error: Error while starting container idling: Error: (HTTP code 400) unexpected - starting container with non-empty request body was deprecated since v1.10 and removed in v1.12 
    at /usr/local/lib/node_modules/resin-cli/node_modules/resin-sync/build/docker-utils.js:301:15
    at tryCatcher (/usr/local/lib/node_modules/resin-cli/node_modules/bluebird/js/release/util.js:16:23)
    at Promise._settlePromiseFromHandler (/usr/local/lib/node_modules/resin-cli/node_modules/bluebird/js/release/promise.js:512:31)
    at Promise._settlePromise (/usr/local/lib/node_modules/resin-cli/node_modules/bluebird/js/release/promise.js:569:18)
    at Promise._settlePromise0 (/usr/local/lib/node_modules/resin-cli/node_modules/bluebird/js/release/promise.js:614:10)
    at Promise._settlePromises (/usr/local/lib/node_modules/resin-cli/node_modules/bluebird/js/release/promise.js:689:18)
    at Async._drainQueue (/usr/local/lib/node_modules/resin-cli/node_modules/bluebird/js/release/async.js:133:16)
    at Async._drainQueues (/usr/local/lib/node_modules/resin-cli/node_modules/bluebird/js/release/async.js:143:10)
    at Immediate.Async.drainQueues (/usr/local/lib/node_modules/resin-cli/node_modules/bluebird/js/release/async.js:17:14)
    at runCallback (timers.js:672:20)
    at tryOnImmediate (timers.js:645:5)
    at processImmediate [as _immediateCallback] (timers.js:617:5)

Using this Dockerfile:

FROM resin/raspberry-pi-alpine
CMD while : ; do echo "Idling..."; sleep ${INTERVAL=600}; done

#10

@d.imade oh, sorry, there was this one more thing on my mind, and forgot by the time writing to you…

There’s this issue that is pending for resin-cli because of the update to Docker 17.03:

We are working on a fix for this (see the linked conversation on Github). In the meantime using resinOS 2.0.6 (which has earlier Docker version) can be a workaround.

Sorry for this, really piled up for the moment, but getting there.


#11

@imrehg, using resinOS 2.0.6, the “idling” image doesn’t seem to persist. The container runs for a certain amount of time and then closes on it’s own. Doesn’t show up when I SSH into my RPi and run docker ps


#12

@d.imade did you git push any code to your application before doing the local push?


#13

For clarity, what I’ve meant above:

  1. git push resin master any working code to the application on resin, the idling is an example project that is very light.
  2. once there’s any code successfully pushed to the application, if you provision a device, and let it download this first code, afterwards it will be put into local mode correctly with the dashboard switch
  3. resin local push your own application to this Local Mode device (you don’t have to care about the idling project at all, it is a “quickfix” until the local mode setting fixes are released)

Sorry if it is confusing, and thanks for bearing with us!


#14

Manage to get the workaround going, thanks for the help. Will be looking for the update that fixes the issue


#15

Thanks, will do our best to ping you when the update is released.


#16

Hey @d.imade, the issue for resin local push on recent ResinOS devices has just been fixed, get the changes with updating resin-cli to 6.3.0! So now you should be able to use resinOS 2.2.0 that was just released this week.

(Just a note, that the “first have to push code to the application before local mode can be enabled” is still outstanding, but you should be set with that)