Add docker and compose files

[ibnesayeed]

Adding dockerfiles and making docker images available in the DockerHub would be nice.

Additionally, since it has dependency on IPFS, it would be nice to also provide a docker-compose file to make "one command and ready to rock" experience.

[machawk1]

@ibnesayeed I believe a Dockerfile already exists for ipfs. We might use this as the basis.

[victorb]

Should be relatively simple to use IPFS with a docker-compose file. One example:

version: '2'
services:
  daemon:
    image: ipfs/go-ipfs:v0.4.3-rc2
    volumes:
      - ./ipfs:/data/ipfs
    ports:
      - "4001:4001"
      - "4002:4002"
      - "5001:5001"
      - "8080:8080"
    environment:
      - IPFS_LOGGING=
    restart: always

You can also find a list of the tags here: https://hub.docker.com/r/ipfs/go-ipfs/tags/

[machawk1]

@VictorBjelkholm The daemon ports can be customized by a user so ought to be parameterized.

[ibnesayeed]

The daemon ports can be customized by a user so ought to be parameterized.

You can put them in ENV vars and use those variables instead. However, docker-compose files are meant to be customized as necessary and then used. Compose files are nothing but a handy way of storing all the parameters in a well structured format that you would otherwise write in one or more long flag decorated docker run (and some other) commands.

[ibnesayeed]

I have added a Dockerfile, but it is not usable due to some hard coding and other issues in the code.

[machawk1]

Hmm, the port is hard-coded in the docker file. Is there a better way to do this if the user wants to use a different port without needing to change the Dockerfile? The preliminary Dockerfile has been moved to the issue-70 branch. https://github.com/oduwsdl/ipwb/tree/issue-70

[ibnesayeed]

Hmm, the port is hard-coded in the docker file. Is there a better way to do this if the user wants to use a different port without needing to change the Dockerfile?

This is perfectly fine to hard-code this port to the default value. Because, when services run inside a container, they don't conflict with the ports of host or other containers. If the service is to be exposed on a different port, user can simply map the internal container port to any host port at run time. However, if this is something we must need to provide a way to allow overwriting, environment variable would be one way to go. Other than that, without any change it is still possible to run the service on a different port and map it, but in that case this port will also be exposed from the container, though it wont have anything to serve on it.

I think this change should have gone in a branch other than master, @ibnesayeed , until we figured it out.

It is a non-conflicting unobtrusive addition to the repo, hence a branch would have been unnecessary. With this being pushed to the master branch, it would be easier to fix those issues in the repo that are preventing it to be run in an isolated environment. We can easily build an image, test it, and fix things as necessary.

[ibnesayeed]

I looked at this ticket again as I was thinking about writing a Compose file to make the deployment easier. I again feel like moving Dockerfile to a separate branch instead of keeping it in the master was not a wise idea and unnecessary action to push a potential progress back.

[machawk1]

@ibnesayeed Go ahead and put together the Docker files in a separate branch and merge to master when you feel it's working.

[ibnesayeed]

There is nothing wrong in the Dockerfile that I pushed to master before, which was then isolated in issue-70 branch. It should start working when the support for Py3 is up to the mark. Keeping it in the master branch would have made testing the support for Py3 so much easier. I can certainly make changes in the Docfkerfile to use Py2, in which case it would presumably start working, but that will be one less reason to support Py3 which I don't want to encourage.

Dockerfile is not part of the code logic, hence it does not break anything. If the image build is not working due to some issue in the Dockerfile, that can be considered an incomplete thing and should be kept aside from the main code. However, if the issue is in the code other than Dockerfile, then the rationale of keeping it aside is not reasonable. Basically, that means the branch for, say, docker-fix, need to keep merging every change in the master until it starts building successfully. I will take the analogy of CI systems here, if the builds fail (not because of an issue in, say, .travis.yml), we do not blame CI system for that, we keep that in the main branch while fixing the code until it builds successfully.

[machawk1]

I can certainly make changes in the Docfkerfile to use Py2

Please do, test to make sure it's working, then push it to master.

[ibnesayeed]

349 is a showstopper to this.

[ibnesayeed]

While I would like the decoupling of IPWB from IPFS, I have actually updated the Dockerfile in #351 to make it work in a monolithic way.

[ibnesayeed]

@machawk1 I think we can close this issue for now. We can revisit the Dockerfile once we have IPWB server decoupled from the IPFS daemon.