[WIP] Dockerfile

[Haidy777]

Description

WIP Version of a Dockerfile for kimai2
As mentioned in #284

Types of changes

• New feature (non-breaking change which adds functionality)

Works with php:7.2-apache as base. Maybe there should also be a Dockerfile for people preferring nginx? Also it's rather large (about 650MB currently), but I think this could be optimized.

Currently the login-page shows but you can't login.

[kevinpapst]

Thanks for the work so far!

You should add the following commands, to create and pre-fill the SQLite database:

bin/console doctrine:database:create
bin/console doctrine:schema:create
bin/console doctrine:migrations:version --add --all
sudo -u www-data bin/console cache:warmup --env=prod
bin/console kimai:create-user admin admin@example.com ROLE_SUPER_ADMIN admin

This will create the SQLite file, the tables and the user admin/admin

[Haidy777]

I thought about that, but that would overwrite the existing database on every container initialisation. Or do you check if a database already exists when running those scripts?

[dysonspherelab]

Referring to my comment #284 (comment)

Login would work if a mysql container is run along with this container.

[Haidy777]

@dysonspherelab I will test this later today, but I mounted the "data"-directoy from the container and ran the commands mentioned in the readme (database:create....), it did create the sqlite File inside the share inclusive the user I created. Not sure why I'm getting a 500 at login. I'll have to dig into the apache logs.

[kevinpapst]

@Haidy777 No Kimai doesn't. But why don't you check it in the Dockerfile?

if [ ! -f var/data/kimai.sqlite ]; then 
# commands from above
fi

You could do the the same for composer install and check if the vendor/directory exists and only run composer if not.

@dysonspherelab I don't mind having a second "full-fledged" docker-compose version with MySQL. If you want: go ahead and submit another PR. I am happy to test it!
You have a lot of DevOps knowledge, so do you have ideas on how to improve this PR? But please consider that I'd like to see SQLite here ;-)

[kevinpapst]

@Haidy777 Regarding the 500: probably wrong permission for the directories in var/? If the log or cache folder are not writeable you see a 500.

[dysonspherelab]

@dysonspherelab I don't mind having a second "full-fledged" docker-compose version with MySQL. If you want: go ahead and submit another PR. I am happy to test it!
You have a lot of DevOps knowledge, so do you have ideas on how to improve this PR? But please consider that I'd like to see SQLite here ;-)

@kevinpapst I have some devops knowledge, we are running a consulting business on it :)
Sure, I would create a new PR soon with the mysql image included in docker-compose.yaml
Regarding SQLite, it can be done by adding a new volume (persistent storage) to docker container and saving the data inside of that. I will look into it further, but mysql is better for production systems in my opinion. Also as @Haidy777 has mentioned this image is quite heavy in size it would be better to use any small base image for this. Like this one https://hub.docker.com/r/roadiz/php72-nginx-alpine/~/dockerfile/

I am not a good php developer, I may need your help to port this app on above base image.

[Haidy777]

@Haidy777 Regarding the 500: probably wrong permission for the directories in var/? If the log or cache folder are not writeable you see a 500.

I' will check that.

@dysonspherelab I don't mind having a second "full-fledged" docker-compose version with MySQL. If you want: go ahead and submit another PR. I am happy to test it!
You have a lot of DevOps knowledge, so do you have ideas on how to improve this PR? But please consider that I'd like to see SQLite here ;-)

@kevinpapst I have some devops knowledge, we are running a consulting business on it :)
Sure, I would create a new PR soon with the mysql image included in docker-compose.yaml
Regarding SQLite, it can be done by adding a new volume (persistent storage) to docker container and saving the data inside of that. I will look into it further, but mysql is better for production systems in my opinion. Also as @Haidy777 has mentioned this image is quite heavy in size it would be better to use any small base image for this. Like this one https://hub.docker.com/r/roadiz/php72-nginx-alpine/~/dockerfile/

I am not a good php developer, I may need your help to port this app on above base image.

Yes, currently it is relatively big, but I'm thinking about starting from another base image (not php:7.2-apache) maybe directly from a php-alpine or maybe directly from apache with php separately installed, as the "raw" php images have almost every module installed as far as I know.

[Haidy777]

@Haidy777 No Kimai doesn't. But why don't you check it in the Dockerfile?

if [ ! -f var/data/kimai.sqlite ]; then 
# commands from above
fi

You could do the the same for composer install and check if the vendor/directory exists and only run composer if not.

@dysonspherelab I don't mind having a second "full-fledged" docker-compose version with MySQL. If you want: go ahead and submit another PR. I am happy to test it!
You have a lot of DevOps knowledge, so do you have ideas on how to improve this PR? But please consider that I'd like to see SQLite here ;-)

Thinking about, we can't do that in the Dockerfile, as at the time of the Image-Build there will never be a kimai.sqlite 😄

[Haidy777]

@dysonspherelab I will test this later today, but I mounted the "data"-directoy from the container and ran the commands mentioned in the readme (database:create....), it did create the sqlite File inside the share inclusive the user I created. Not sure why I'm getting a 500 at login. I'll have to dig into the apache logs.

Checked the file permissions and changed them. But I meant 302, sorry for that. Dose kimai write logs somewhere?
Could it be because I'm softlinking from /usr/src/public to /var/www/html

[kevinpapst]

Yes in var/logs/.

I don't understand your comment, first you say

that would overwrite the existing database on every container initialisation

and then after having a valid workaround (which btw I have seen multiple times in docker images) you say

Thinking about, we can't do that in the Dockerfile, as at the time of the Image-Build there will never be a kimai.sqlite

Isn't that an opposite opinion? ;-)

Also, users might have created the database upfront or imported it from another installation ... then they don't want to have it replaced. If the container boots and doesn't find the file, it will take care of creating it. I don't see the problem here...
But probably it's better to grep the proper database name from the .env file instead of hardcoding it.

[Haidy777]

I'm sorry for the confusion. The Dockerfile get's run/built before the container is created, some projects have it automated in Travis.
So if [ ! -f /usr/var/data/kimai.sqlite ]; would always return true, as at build time there is no Database.
Later, if you start the image and create the share for /usr/src/var/data the contents of that folder inside the image will get destroyed.

[kevinpapst]

Ah, sorry for not being clear enough. Its a bit ago that I created a Dockerfile myself. I checked the docu again and what I actually meant was doing that in anl ENTRYPOINT script:
https://docs.docker.com/engine/reference/builder/#entrypoint
http://crosbymichael.com/dockerfile-best-practices.html

[Haidy777]

Oh, I didn't know about that 😄 I'll test that this evening or tomorrow if I can.

[kevinpapst]

Hey @Haidy777, in the meantime another Docker image was contributed which uses my favorite setup for Kimai 2 with nginx.
But I really like your solution, so I added a link to your image here.
Please keep the branch alive or put the dockerfile in its own repo.

[Haidy777]

Sure, I'll leave it as is :)

[Lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. If you use Kimai on a daily basis, please consider donating to support further development of Kimai.