8000 Add docker image to docker hub · Issue #33 · wefork/wekan · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Add docker image to docker hub #33

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
fmonthel opened this issue Nov 29, 2016 · 50 comments
Closed

Add docker image to docker hub #33

fmonthel opened this issue Nov 29, 2016 · 50 comments
Assignees
@pierreozoux

Comments

@fmonthel
Copy link

Hi

We're using docker compose and should be a good thing to have docker image on docker hub
Thanks
@fmonthel fmonthel mentioned this issue Nov 29, 2016
Closed
@pierreozoux pierreozoux self-assigned this Nov 29, 2016
@pierreozoux
Copy link

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
Copy link
Author

Ok thanks Pierre

@verymilan
Copy link

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.

@xet7 xet7 mentioned this issue Dec 14, 2016
Closed
@weaktyper
Copy link
weaktyper commented Dec 14, 2016 •
edited
Loading

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
Copy link
Member
xet7 commented Dec 14, 2016

@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
Copy link
Member
xet7 commented Dec 14, 2016

@weaktyper

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

@weaktyper
Copy link
weaktyper commented Dec 14, 2016 •
edited
Loading

@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
Copy link
Member
xet7 commented Dec 14, 2016

@weaktyper

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

@fmonthel
Copy link
Author
fmonthel commented Dec 14, 2016 via email

@weaktyper
Copy link
weaktyper commented Dec 14, 2016 •
edited
Loading

@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
Copy link
pierreozoux commented Dec 15, 2016 via email

@xet7
Copy link
Member
xet7 commented Dec 15, 2016

@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
Copy link
Member
xet7 commented Dec 15, 2016

@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
Copy link
weaktyper commented Dec 15, 2016 •
edited
Loading

@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
Copy link

This example is a production image.

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

@xet7
Copy link
Member
xet7 commented Dec 15, 2016

@dwrensha

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

@dwrensha
Copy link

v0.10.45

@xet7 xet7 mentioned this issue Jan 14, 2017
Closed
@xet7
Copy link
Member
xet7 commented Jan 15, 2017

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.

@xet7 xet7 mentioned this issue Jan 15, 2017
Closed
@pierreozoux pierreozoux mentioned this issue Jan 16, 2017
Closed
@b-long
Copy link
b-long commented Jan 16, 2017

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

@weaktyper
Copy link

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
Copy link
stephenmoloney commented Jan 17, 2017 •
edited
Loading

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

#71

@xet7
Copy link
Member
xet7 commented Jan 17, 2017

@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
Copy link
Member
xet7 commented Jan 17, 2017

@stephenmoloney

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

@xet7
Copy link
Member
xet7 commented Jan 17, 2017

@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
Copy link

Sorry for the spam. I just replied to the wrong email. #33 (comment) was intended to answer #71 (comment) (which was posted here by accident).
Sorry for that.

@stephenmoloney
Copy link
stephenmoloney commented Jan 17, 2017 •
edited
Loading

@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
Copy link
Member
xet7 commented Jan 17, 2017

@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
Copy link

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
Copy link
Member
xet7 commented Jan 17, 2017

@martingabelmann

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

@martingabelmann
Copy link

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

@stephenmoloney
Copy link
stephenmoloney commented Jan 17, 2017 •
edited
Loading

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
Copy link
pcads commented Jan 18, 2017

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
Copy link
stephenmoloney commented Jan 18, 2017 •
edited by xet7
Loading

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

See #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
Copy link
yatusiter commented Jan 20, 2017 •
edited
Loading

@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
Copy link

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

@yatusiter yatusiter mentioned this issue Jan 20, 2017
Closed
@pcads
Copy link
pcads commented Jan 23, 2017 •
edited
Loading

@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
Copy link
yatusiter commented Jan 24, 2017 •
edited
Loading

@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
Copy link
pcads commented Jan 24, 2017

@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
Copy link
ghost commented Jan 25, 2017 •
edited by ghost
Loading

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
Copy link
stephenmoloney commented Jan 25, 2017 •
edited
Loading

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
Copy link
DMCShep commented Jan 27, 2017

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
Copy link
stephenmoloney commented Jan 28, 2017 •
edited
Loading

@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
Copy link
DMCShep commented Jan 28, 2017

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
Copy link
ghost commented Jan 31, 2017 •
edited by ghost
Loading

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

@xet7
Copy link
Member
xet7 commented Feb 1, 2017

@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
Copy link
ghost commented Feb 1, 2017

It works for me

@xet7
Copy link
Member
xet7 commented Feb 1, 2017

@centigrade-thomas-becker

What docker commands did you use to run it?

@xet7
Copy link
Member
xet7 commented Feb 1, 2017

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
Copy link
Danny4927 commented Feb 1, 2017 •
edited
Loading

@xet7 thank you very much. it also works for me 👍

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 xet7 mentioned this issue Feb 8, 2017
Closed
@xet7
Copy link
Member
xet7 commented Feb 8, 2017

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.

@xet7 xet7 closed this as completed Feb 8, 2017
@xet7 xet7 mentioned this issue Feb 27, 2017
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@pierreozoux pierreozoux

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
0