Add docker image to docker hub

[fmonthel]

Hi

We're using docker compose and should be a good thing to have docker image on docker hub Thanks

[pierreozoux]

I'll take care of that once I have a bit of time.

Just note, that this process is really slow (It will take months).

[fmonthel]

Ok thanks Pierre

[verymilan]

Maybe documentation for an own image would be also nice for noobs like me. :) I've tried the official dockerfile once without success - maybe i'll switch to docker-compose somewhen to be able to change the assets.

[weaktyper]

I have a working build process for Docker but I'm waiting on a pull request in another repository for building meteor apps. I'd like to wait a bit more and see what happens there. Failing that, the weaktyper branch could be used directly.

I have considered three options for building wekan:

1. A weaktyper/wekan-docker-compose (or wefork/wekan-docker-compose) repo for a docker build process that has a dependency on this build process. and/or
2. A wefork/docker-wekan:onbuild image that is referred to in the Dockerfile in the root of the project wekan/wefork. This option would require a separate repo (eg wefork/docker-wekan) to be built to be maintained and uploaded to the Dockerhub. This is how it is currently done in wekan/wekan. and/or
3. A Dockerfile in the root folder that does the entire build process from scratch and then a separate docker-compose.yml file in the root folder of wefork/wekan.

Any thoughts/suggestions?

Option 1, weaktyper/wekan-docker-compose is feasible presently without any changes to wefork/wekan.

Note: I haven't create the repository weaktyper/wekan-docker-compose yet. 🛠

[xet7]

@weaktyper

Please add pull request to Wefork devel branch using Option 1 and Development build option: FROM jshimko/meteor-launchpad:devbuild

Because download and install Meteor every time is the one slowing me down a lot, I've been trying to find a way to avoid it. Also many have asked for ability to install offline, this would make it easier.

[xet7]

@weaktyper

If your pull request gets accepted we can change Dockerfile later.

[weaktyper]

@xet7, Even if the pull request is accepted, just adding FROM jshimko/meteor-launchpad:devbuild won't work. Wefork are using a specific version of NODEJS right now @0.10.48 which is quite old. The build process would need to match the required node version exactly. FROM jshimko/meteor-launchpad:devbuild uses a default version of nodejs = 4.6.2 This build would not work for wefork... This is my understanding at least.

As Wefork is pinned to an old nodejs version, I think wefork could do with it's own build at this stage. A repository called something like wefork/wekan-launchpad or wefork/wekan-build or whatever you prefer could be created for this purpose. I could do a PR for that.

Then it would be feasible add FROM wefork/wekan-launchpad:devbuild to the Dockerfile. Another benefit of making releases of wefork/wekan-launchpad is to match the releases in wefork/wekan.

[xet7]

@weaktyper

I created https://github.com/wefork/wekan-launchpad repo, you can add PR for that.

[fmonthel]

Honestly the option 2 is not the good one to keep good image uptodate with the production one (that's my concern currently with official wekan repo)

By the way many thanks !

Sent from my iPhone

On 14 Dec 2016, at 14:04, Lauri Ojansivu notifications@github.com wrote:

@weaktyper

Please add pull request to Wefork devel branch using Option 1 and Development build option: FROM jshimko/meteor-launchpad:devbuild

Because download and install Meteor every time is the one slowing me down a lot, I've been trying to find a way to avoid it. Also many have asked for ability to install offline, this would make it easier.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[weaktyper]

@fmonthel I don't really mind but @xet7 prefers this approach due to the time it takes to build from scratch.

I think if the nodejs version was specified somewhere in the wekan project it would be helpful for the build. Perhaps the version of nodejs should be specified somewhere in the project -- eg package.json - as a dependency?

@xet7, any reasons to not depend on a specific version of nodejs? How is anyone to know if it is not a dependency?

My current thoughts are to try option 1 or option 2 first. Only thing about option 2 is that it requires push to an automated build to the Dockerhub - something i don't know much about.

.....

[pierreozoux]

My 2 cents, if we want an official image, it has to look like this: https://github.com/RocketChat/Docker.Official.Image/blob/master/Dockerfile

Cheers!

Pierre

On 14-12-2016 23:56, weaktyper wrote:

@fmonthel https://github.com/fmonthel I don't really mind but @xet7 https://github.com/xet7 prefers this approach. I think if the nodejs version was specified somewhere in the wekan project it would be helpful for the build.

Perhaps the version of nodejs should be specified somewhere in the project -- eg |package.json| - as a dependency?

@xet7 https://github.com/xet7, any reasons to not depend on a specific version of nodejs? How is anyone to know if it is not a dependency?

My current thoughts are to try option 1 or option 2 first. Only thing about option 2 is that it requires push to an automated build to the Dockerhub - i need to make some time to figure that that process.

.....

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/wefork/wekan/issues/33#issuecomment-267194608, or mute the thread https://github.com/notifications/unsubscribe-auth/ABxvHXqLDbOlvjbQ2RVgswF8R0N-ASzyks5rIIJAgaJpZM4K-5Nu.

-- I use PGP to protect our privacy, if you want to know more, you can follow this https://emailselfdefense.fsf.org/en/

If you have further questions, please do not hesitate to ask. You can verify my public key here: https://keybase.io/pierreozoux

[xet7]

@pierreozoux

• Does that kind of Dockerfile support having Meteor base image so Meteor does not need to installed every time after changes?
• Does this mean that we need different Dockerfile for 1) official image and 2) creating local Docker container where Meteor does not need to be installed every time again?

@weaktyper

Yes specific version of nodejs is dependency, Wekan does not work with newer versions yet. Newest 0.10.x is 0.10.48 and while Travis CI currently builds using 0.10.40 I'm not aware of reason to use that older version.

[xet7]

@pierreozoux

That Rocket.Chat way looks nice, so official image is at: https://github.com/RocketChat/Docker.Official.Image

So there could be similarly those different repos like: https://github.com/wefork/Docker.Official.Image https://github.com/wefork/Docker.Base.Image

And for that Dev version, where Meteor does not need to be installed againe there could be for example: https://github.com/wefork/Docker.Dev.Image

Could this work? Does somebody have suggestions for improvements in repo naming, how to do this correctly etc?

[weaktyper]

@xet7 I was asking if the node_version could be hard coded into the wefork/wekan root project somewhere though? Reading issues isn't a great way to 'guess' the version, IMO.

About the repositories, wefork could start by seeing if it is possible to generate multiple images from a single repository with folders .. eg official, onbuild, devbuild, etc.

[pierreozoux]

This example is a production image.

Unfortunately, I think it is better to have 2 images, one for dev, one for prod.

[xet7]

@dwrensha

What version of node is used to run Wefork on Sandstorm?

[dwrensha]

v0.10.45

[xet7]

Continuing discussion from #58 by @b-long

Have you all seen this? https://forums.meteor.com/t/docker-team-up-to-create-a-reference-docker-image-for-meteor/30829/60

I have not seen that. I did read that thread, and MiniMeteor seems interesting: https://github.com/aedm/minimeteor https://hub.docker.com/r/aedm/meteor/tags/

I have not tried it yet.

[b-long]

Thanks @xet7 😃 I don't think I'll have time to help out, but am willing to test!

[weaktyper]

There are quite a few approaches I think to this problem. One approach I thought of was to build the app in intermediate images/containers which will be removed and finally serve the built app with an alpine image. I haven't tested this yet though. The reason I have held back on this is that I have been trying to come up with the most appropriate way... It's not clear.

[stephenmoloney]

I have changed the Dockerfile and the docker-compose.yml file. They are intended for building locally. The buildtime is very slow and the image is huge so I don't really see this as a long term solution. However, it is better than nothing in my opinion.

Let me know if you would like me to submit a pull request on this. Changes

https://github.com/wefork/wekan/pull/71

[xet7]

@stephenmoloney

Thanks, that's a good starting point. Previously today I also created new VirtualBox appliance: https://wekan.xet7.org and fixed Install from source instructions: https://github.com/wefork/wekan/wiki/Install-from-source

[xet7]

@stephenmoloney

You can add wiki page about Docker to: https://github.com/wefork/wekan/wiki

[xet7]

@martingabelmann

Those dependencies are needed to compile fibers etc Node.js extensions, but after compiling they are not needed. You could try does the resulting 223MB image run Wekan successfully.

Have just one RUN block formatted escaping with \ line breaks, it's readable enough, and size savings are more important.

It you get Wekan working with your changes, create new pull request to change today merged Dockerfile etc.

I have not tested yet does Alpine based Docker baseimage behave correctly.

[martingabelmann]

Sorry for the spam. I just replied to the wrong email. https://github.com/wefork/wekan/issues/33#issuecomment-273251790 was intended to answer https://github.com/wefork/wekan/pull/71#issuecomment-273251558 (which was posted here by accident).
Sorry for that.

[stephenmoloney]

@martingabelmann You should make a pull request for those changes if the image size reduction is that substantial. 👍 You will run into issues with Alpine + meteor build process as far as I know. I have an idea as a workaround but it is complex so no time for now on this but if i get to it, a tiny final image may be possible.

@xet7 I have added some changes to the wiki if you would like to review them and perhaps merge them in manually to the the wefork wiki. https://github.com/stephenmoloney/wekan/wiki. This way the images can also be merged in - just adding pages doesn't allow adding images.

[xet7]

@martingabelmann

I also did sometime try to run Docker in Alpine but did run into errors.

@stephenmoloney

Please add your changes directly to Wefork wiki, that has page history and comparing built-in.

[martingabelmann]

Another approach which is not far away form status quo would be to do the docker build with travis and have a dockerhub integration there (i.e. push the image to dockerhub from travis).

[xet7]

@martingabelmann

Is there documentation somewhere how to make travis and dockerhub integration?

[martingabelmann]

https://docs.travis-ci.com/user/docker#Building-a-Docker-Image-from-a-Dockerfile

[stephenmoloney]

I've added some extras to the wiki...

localhost: https://github.com/wefork/wekan/wiki/Docker

https using nginx-proxy with letsencrypt: https://github.com/wefork/wekan/wiki/Docker-NginxProxy

I have the nginx-proxy with letsencrypt working... the docker-compose.yml in the wiki is an example. There may be some tweaking required.

I suggest blocking signup once the container is initiated and the first signup is complete. https://github.com/wefork/wekan/wiki/Docker#block-further-signup-for-security-reasons

[pcads]

Seems the ARGs in Dockerfile don't work, they are not passed to the RUN command.

I mean these: ARG NODE_VERSION=v0.10.48 ARG METEOR_RELEASE=1.3.5.1 ARG NPM_VERSION=3.10.10 ARG ARCHICTECTURE=linux-x64 ARG SRC_PATH=./

[stephenmoloney]

@pcads Are you using the latest version? I made a pull request that fixed this issue.

See https://github.com/wefork/wekan/pull/73

Also, check your docker-compose and docker-engine are latest versions.

This is an example and it works after that pull request.

https://github.com/wefork/wekan/wiki/Docker#build-the-image-and-start-the-containers-with-custom-parameters-not-recommended

[yatusiter]

@pcads @stephenmoloney
I got the same problem here, and my docker-compose & docker version is :

docker-compose -v docker-compose version 1.10.0, build 4bd6f1a docker -v Docker version 1.13.0, build 49bf474

compose build error :

Processing triggers for ca-certificates ... Updating certificates in /etc/ssl/certs... 171 added, 0 removed; done. Running hooks in /etc/ca-certificates/update.d....done. --2017-01-19 17:51:18-- https://nodejs.org/dist//node--linux-x64.tar.gz Resolving nodejs.org (nodejs.org)... 104.20.23.46, 104.20.22.46, 2400:cb00:2048:1::6814:162e, ... Connecting to nodejs.org (nodejs.org)|104.20.23.46|:443... connected. HTTP request sent, awaiting response... 404 Not Found 2017-01-19 17:51:20 ERROR 404: Not Found.

As you see, ${NODE_VERSION} is not replaced in the Dockfile RUN command.

After checked the Dockerfile & docker-compose.yml , I found that Dockerfile use ARCHICTECTURE and docker-compose.yml use ARCHITECTURE.

Retried for replace ARCHICTECTURE for ARCHITECTURE in Dockfile, the error is : https://nodejs.org/dist//node--.tar.gz

$ARCHITECTURE is missing too!

It's obviously docker-compose.yml args is assign null value to the RUN command,

execute set env vars command in the guide doc https://github.com/wefork/wekan/wiki/Docker, REMEMBER to correct the ARCHITECTURE spell error in Dockfile ,

echo 'NODE_VERSION=v6.6.0' >> .env && \ echo 'METEOR_RELEASE=1.4.2.3' >> .env && \ echo 'NPM_VERSION=4.1.2' >> .env && \ echo 'ARCHITECTURE=linux-x64' >> .env && \ echo 'SRC_PATH=./' >> .env;

then run : sudo docker-compose up -d

everything works fine now.

[stephenmoloney]

no need for the pull request, I've already fixed it in PR 81 . was waiting to add other changes. thanks anyways. :)

[pcads]

@yatusiter could you please confirm if you have this issue #58 with the containers? Just wanna make sure I was not doing anything wrong. I tried run containers on Ubuntu & MacOS, containers run without issue except I can't upload file.

[yatusiter]

@pcads I encounted with some network problem and fail to build image , then I run wekan on ubuntu 16.04 from source build.

The mongdb version is 2.6.10, hope that will help you out . Maybe you should change the docker-composer file mongo image from 3.4 to 2.6.12 and rebuild the image?

I'll try the docker later & update the information

mongod --version db version v2.6.10

[pcads]

@yatusiter @xet7 confirmed, with mongodb 2.6.10 , I don't have #58 issue. Looks like there might be a bug in nodejs mongodb3.4 driver

[ghost]

I have the same problem as @yatusiter. When I try to build the container with docker-compose up -d it fails with an error 404:

[...]
Resolving nodejs.org (nodejs.org)... 104.20.23.46, 104.20.22.46, 2400:cb00:2048:1::6814:162e, ...
Connecting to nodejs.org (nodejs.org)|104.20.23.46|:443... connected.
HTTP request sent, awaiting response... 404 Not Found
2017-01-24 23:12:17 ERROR 404: Not Found.

ERROR: Service 'wekan' failed to build: The command '/bin/sh -c useradd --user-group --system --home-dir /home/wekan wekan &&
     apt-get update -y && apt-get install -y --no-install-recommends ${BUILD_DEPS} &&         GOSU_ARCHITECTURE="$(dpkg --print-architecture | awk -F- '{ print $NF }')" &&     wget -O /usr/local/bin/gosu "https://github.com/tianon/gosu/releases/download/${GOSU_VERSION}/gosu-${GOSU_ARCHITECTURE}" &&     wget -O /usr/local/bin/gosu.asc "https://github.com/tianon/gosu/releases/download/${GOSU_VERSION}/gosu-${GOSU_ARCHITECTURE}.asc" &&     export GNUPGHOME="$(mktemp -d)" &&     gpg --keyserver ha.pool.sks-keyservers.net --recv-keys B42F6819007F00F88E364FD4036A9C25BF357DD4 &&     gpg --batch --verify /usr/local/bin/gosu.asc /usr/local/bin/gosu &&     rm -R "$GNUPGHOME" /usr/local/bin/gosu.asc &&     chmod +x /usr/local/bin/gosu &&         wget https://nodejs.org/dist/${NODE_VERSION}/node-${NODE_VERSION}-${ARCHITECTURE}.tar.gz &&     wget https://nodejs.org/dist/${NODE_VERSION}/SHASUMS256.txt.asc &&         grep ${NODE_VERSION}-${ARCHITECTURE}.tar.gz SHASUMS256.txt.asc | shasum -a 256 -c - &&     export GNUPGHOME="$(mktemp -d)" &&     gpg --keyserver pool.sks-keyservers.net --recv-keys 9554F04D7259F04124DE6B476D5A82AC7E37093B &&     gpg --keyserver pool.sks-keyservers.net --recv-keys 94AE36675C464D64BAFA68DD7434390BDBE9B9C5 &&     gpg --keyserver pool.sks-keyservers.net --recv-keys FD3A5288F042B6850C66B31F09FE44734EB7990E &&     gpg --keyserver pool.sks-keyservers.net --recv-keys 71DCFD284A79C3B38668286BC97EC7A07EDE3FC1 &&     gpg --keyserver pool.sks-keyservers.net --recv-keys DD8F2338BAE7501E3DD5AC78C273792F7D83545D &&     gpg --keyserver pool.sks-keyservers.net --recv-keys C4F0DFFF4E8C1A8236409D08E73BC641CC11F4C8 &&     gpg --keyserver pool.sks-keyservers.net --recv-keys B9AE9905FFD7803F25714661B63B535A4C206CA9 &&     gpg --refresh-keys pool.sks-keyservers.net &&     gpg --verify SHASUMS256.txt.asc &&     rm -R "$GNUPGHOME" SHASUMS256.txt.asc &&         tar xvzf node-${NODE_VERSION}-${ARCHITECTURE}.tar.gz &&     rm node-${NODE_VERSION}-${ARCHITECTURE}.tar.gz &&     mv node-${NODE_VERSION}-${ARCHITECTURE} /opt/nodejs &&     ln -s /opt/nodejs/bin/node /usr/bin/node &&     ln -s /opt/nodejs/bin/npm /usr/bin/npm &&         npm install npm@${NPM_VERSION} -g &&
  npm install -g node-gyp &&     npm install -g fibers &&         cd /home/wekan/ &&     chown wekan:wekan --recursive /home/wekan &&     curl https://install.meteor.com -o ./install_meteor.sh &&     sed -i "s|RELEASE=.*|RELEASE=${METEOR_RELEASE}\"\"|g" ./install_meteor.sh &&     echo "Starting meteor ${METEOR_RELEASE} installation...   \n" &&     chown wekan:wekan ./install_meteor.sh &&     gosu wekan:wekan sh ./install_meteor.sh &&         cd /home/wekan/app &&     gosu wekan /home/wekan/.meteor/meteor npm install --save xss &&     gosu wekan /home/wekan/.meteor/meteor build --directory /home/wekan/app_build &&     cd /home/wekan/app_build/bundle/programs/server/ &&     gosu wekan npm install &&     mv /home/wekan/app_build/bundle /build &&         apt-get remove --purge -y ${BUILD_DEPS} &&     apt-get autoremove -y &&     rm -R /var/lib/apt/lists/* &&     rm -R /home/wekan/.meteor &&
 rm -R /home/wekan/app &&     rm -R /home/wekan/app_build &&     rm /home/wekan/install_meteor.sh' returned a non-zero code: 8

I am running Windows 10 and I am using the latest wekan source. The dockerfile already contains all the fixes that are mentioned on this isse (ARCHITECTURE spelled correctly, NODE_VERSION in upper case etc.).

It seems all the necessary fixes are in place, yet it does not work for me.

edit: I missed this important part at the very beginning

$ docker-compose up -d
WARNING: The NODE_VERSION variable is not set. Defaulting to a blank string.
WARNING: The METEOR_RELEASE variable is not set. Defaulting to a blank string.
WARNING: The NPM_VERSION variable is not set. Defaulting to a blank string.
WARNING: The ARCHITECTURE variable is not set. Defaulting to a blank string.
WARNING: The SRC_PATH variable is not set. Defaulting to a blank string.
Building wekan
Step 1/13 : FROM debian:wheezy
[...]

[stephenmoloney]

Hi @centigrade-thomas-becker ,

Are you still having this issue? If yes, please document your version of docker and docker-compose.

sudo docker-compose up -d should work as is. The variables are not set because you did not change them & this is recommended.

If you want to change them, they have to be changed in a ./.env file.

https://github.com/wefork/wekan/wiki/Docker

[DMCShep]

Removing these lines from the docker-compose.yml fixes the issue:

      args:
        - NODE_VERSION=${NODE_VERSION}
        - METEOR_RELEASE=${METEOR_RELEASE}
        - NPM_VERSION=${NPM_VERSION}
        - ARCHITECTURE=${ARCHITECTURE}
        - SRC_PATH=${SRC_PATH}

New to git, or I'd do the pull request myself :-)

[stephenmoloney]

@DMCShep

WARNING: The NODE_VERSION variable is not set. Defaulting to a blank string.
WARNING: The METEOR_RELEASE variable is not set. Defaulting to a blank string.
WARNING: The NPM_VERSION variable is not set. Defaulting to a blank string.
WARNING: The ARCHITECTURE variable is not set. Defaulting to a blank string.
WARNING: The SRC_PATH variable is not set. Defaulting to a blank string.

are intended warning messages.

If there is another separate issue, please open a separate issue for it describing it in full.

[DMCShep]

I thought I still got those, I'll double-check. My fix is for the 404 error that centigrade-thomas-becker described, which I got too. It seems that by defining the args in the yml file, they do not get properly defaulted in the dockerfile, and remain blank strings throughout.

Either way, I'll open a new issue when I'm able to document the process better. This one's for adding the dockerfile, not fixing it.

[ghost]

For posterity: The trouble with empty arguments continues in #90

[xet7]

@Danny4927 asked at chat: "Hi. I want to install wekan with the docker image, but the readme says it needs to be updated can i get updated instructions anywehere? This image: https://hub.docker.com/r/mquandalle/wekan/ uses wefork...can i use the official one?"

When I looked at Docker Hub, it seems that official Wekan docker image was built as trusted build when I merged Wefork to Wekan yesterday: https://hub.docker.com/r/mquandalle/wekan/tags/ I can see it from size: latest build is 88 MB and previous build is 258 MB.

Could somebody test does it work? I'll also try myself soon.

[ghost]

It works for me

[xet7]

@centigrade-thomas-becker

What docker commands did you use to run it?

[xet7]

This works for me:

docker run -d --restart=always --name wekan-db mongo:3.2.11

docker run -d --restart=always --name wekan --link "wekan-db:db" -e "MONGO_URL=mongodb://db" -e "ROOT_URL=http://localhost:8080" -p 8080:80 mquandalle/wekan:latest

[Danny4927]

@xet7 thank you very much. it also works for me :+1:

and i found out that the source repository is wekan/wekan, but the linked docs says wefork/wekan. Didn't see that the link goes to wefork (https://github.com/wefork/wekan/wiki/Docker)

[xet7]

Wefork has been merged back to Wekan and after git commits automatic trusted build is generated to official Docker image so it's always up-to-date.

Closing issue.