Add Dockerfile + docker usage

[ruzickap]

I would like to "dockerize" the application, because it has quite a lot php dependencies which I prefer to have inside docker image only.

This is initial commit for creating the Docker image.

[TheFox]

@ruzickap This is a good idea. I actually dockerized some of my projects, and I would rather use a template from another project. And I want to push it to /u/thefox21 Docker Hub.

[samwilson]

This is a great idea!

And I've just realised that my comments here are wrong, in that of course we should include the git clone in the image, because then we're not relying at all on the original clone (which can be removed entirely).

So I think the only required change here is to add some more info to the readme, explaining that after building the image, you can delete the source and the docker run command should be run from whereever (with $PWD substituted for your config.php directory).

If you see what I mean? :-) Sorry for being confusing.

[samwilson]

Why clone the repo again, when it's already accessible locally?

If we're already suggesting people mount their flickr-cli directory as /mnt, could we do away with this clone, and change the entrypoint php arg to /mnt/application.php instead?

This would mean that the Docker set up could be used for people developing flickr-cli as well.

[samwilson]

I think a common usage of the docker setup would be to set up a quick command to upload a directory or backup one's Flickr photos, so perhaps we should give these commands more from that point of view? e.g. as they'd need to be entered as a command alias or similar. Or maybe we provide a launch script?

[TheFox]

I'm currently creating a Dockerfile for that. But the problem with docker run --rm is, as you maybe already know, that the container will be deleted after the command has been executed. But I actually want to keep the config.yml file once I ran auth. And I don't want to store the config.yml in /mnt, which is acutally $PWD on the host system.

[ruzickap]

It's possible to add another volume for do Dockerfile only for config.yml, but you should never store any data into the Docker container. The "containers" should always store / retrieve data only from attached volumes (in my case it's only /mnt).

[ruzickap]

I believe in the future the owner of the repository (application) will bind the repository with Dockerhub so the docker image will be built there. Then the section about building the container can be removed from README.md - because every commit to repository will trigger the build of new docker image (in Docker hub).

[TheFox]

It's possible to add another volume

Yes, this is also my solution.

Another problem with Docker is that docker build does not have a --volume function. This would be greate to use the Composer cache from host ~/.composer. Otherwise I need to create a auth.json and remove it after composer install to not run into GitHub API limit.

[TheFox]

I have now pushed the current development version to Docker Hub as dev. See https://hub.docker.com/r/thefox21/flickr-cli/tags/. Also see develop README: https://github.com/TheFox/flickr-cli/tree/develop

[ruzickap]

Hello.

I'm not sure about the "quality" of the Dockerfile you merged - it's not done the way how the containers should be created.

If you compare your "Docker repository" (https://hub.docker.com/r/thefox21/flickr-cli/) with for example this one "https://hub.docker.com/r/phpmyadmin/phpmyadmin/" you can see the 'tabs' likke "Dockerfile" and "Build Details".

In these tabs you can see the real Dockerfile which was used to build the image (including build details).

In your case - you put the the Docker image of "flickr-cli" manually and there is no way how to check what is it really in the the docker image.

These manually created / pushed docker images may contain some "bad software" hidden inside docker image and a lot of people refuse to run them.

Therefore I prefer to do it the way like it is done for example in phpmyadmin.

[samwilson]

I think an automatically built one sounds good; gives people better security.

And so should we document the Docker deployment as the preferred way of using flickr-cli? i.e. how to install it, how to upgrade, etc.

I'd love to see it as simple as ending up with a flickr-cli command that people can run wherever, pointing to whichever config file they want. (This would also be possible via #23, but of course only for people with PHP and Composer already installed.)

[ruzickap]

I agree with updating the documentation: how to use the the "dockerized flicker-cli" for the users. The developers usually know how to work with docker, how to build docker image, etc... - so it's not necessary to write something like that into the "readme".

Here is the example of the docker repository how it should look like for your flickr-cli Docker Hub account and GitHub repository when "Automated Build" is enabled:

https://hub.docker.com/r/peru/flickr-cli/

@TheFox should do something like that for his Docker Hub: https://hub.docker.com/r/thefox21/flickr-cli/

[TheFox]

Ah, I see. Thank you for the input. I appreciate that.

I now changed the Docker Hub repo. See https://hub.docker.com/r/thefox21/flickr-cli/

Please use the current develop version from this GitHub repo to test the Dockerization locally.
Also see the current README in develop branch. I will update it.

When everything works as expected I will release v1.2.0, which will then be build automatically on Docker Hub. For further feedback regarding to the Dockerization feel free to report it here. :)

[ruzickap]

Looks like when using the docker volumes they are mounted read only (/data) for some strange reason:

$ docker volume create flickrcli                                                                                                                                         
flickrcli

$ docker run --rm -it -u $(id -u):$(id -g) -v "$PWD":/mnt -v flickrcli:/data thefox21/flickr-cli:develop auth
Go to https://www.flickr.com/services/apps/create/apply/ to create a new API key.

 Consumer key:
 > 7xxxxxxxxxxxxxxxxxxxxxxxxxxxx

 Consumer secret:
 > 3xxxxxxxxxxxxxxxxx


                                                        
  [Symfony\Component\Filesystem\Exception\IOException]  
  Failed to touch "/data/config.yml".                   
                                                        

auth [-c|--config [CONFIG]] [-l|--log [LOG]] [-f|--force]

I do not know why... :-(
Anybody else has the same problem ?

[TheFox]

This is very strange. While I wrote this documentation it worked as expected. But now, on a separate PC, I also have this issue. I guess this is because of -u. The $(id -u) is not allowed to write to /data. It's only mounted by root inside the container.

[TheFox]

@ruzickap I fixed the permissions. Please pull the latest develop and test it again.

[ruzickap]

The auth is working fine right now.

In case of upload command I have to specify the config path using --config /data/config.yml parameter.

The test command looks like:

docker run --rm -it -u $(id -u):$(id -g) -v "$PWD":/mnt -v flickrcli:/data thefox21/flickr-cli:develop upload --config=/data/config.yml --tags "test_tags" --sets "test_set" pics_directory

So you have to change the commands in README.md.

[TheFox]

Because the code itself is pretty fucked up. We should do #24 for all commands. The commands don't have a common structure. Some extend from FlickrCliCommand, others don't.

This will be fixed in #27.

[ruzickap]

Ok...
I'll create a new PR with updated README.md to have documented the current state properly.
Once the #27 will be done then we may update it again...

[TheFox]

@ruzickap I refactored everything acording to #27. The code is now cleaner. It's in develop. Please test it.

[ruzickap]

Excellent work :-)
I tested the Docker image and it's working fine...
Please go ahead and release it.
Thank you...

[TheFox]

Thank you. :)

And also thank you for testing.