Open Boldie opened 4 years ago
Maybe this is also related to #1041 #1066
There is a docker container managed by mhubig. Although I'd like to see it be under official namespace of partkeepr. But this is merely for production and not for development.
One problem is that there needs to be a way to run the setup without calling a set of web sites. This is needed as (at the moment according to my understanding) nobody except for @Drachenkaetzchen knows exactly what happens during setup routine. This needs to be done manually in order to make automated builds and tests possible.
It would be much more convinient to do a docker-compose
with PostgreSQL.
And you can export demo site to .sql files (from normal installation) and then import them inside database during intialization.
This is needed as (at the moment according to my understanding) nobody except for @Drachenkaetzchen knows exactly what happens during setup routine.
Well, the code is there.
Also, all setup does is to generate the config.php
file and wraps symfony commands to setup the environment. See https://wiki.partkeepr.org/wiki/Running_PartKeepr_from_GIT#Updating
Well, that is a good source of information. Thank you for the hint @Drachenkaetzchen.
Just a small question at @Drachenkaetzchen and @dromer. Where would we put such files? Some repos I have seen use a subfolder, other use a complete own repo for all sort of CI/CD. What would be your preference for partkeepr? Maybe I can do something here but I want to avoid make the work twice.
I agree with @shafr that a simple docker and/or docker-compose file should be enough to get going.
However it is important that there is a volume mounted for any assets and cache that partkeepr needs. Usually everything is self-contained with docker, but in this case a mounted volume is quite necessary.
@christianlupus I think a dockerfile in the root should be fine. Unless it becomes a 'collection' of files then a subdir to keep it a bit neater.
Well using docker image for composer:1.9.3 causes issues with packages:
Problem 1
- Installation request for fr3d/ldap-bundle dev-master -> satisfiable by fr3d/ldap-bundle[dev-master].
- fr3d/ldap-bundle dev-master requires ext-ldap * -> the requested PHP extension ldap is missing from your system.
Problem 2
- Installation request for moontoast/math 1.1.2 -> satisfiable by moontoast/math[1.1.2].
- moontoast/math 1.1.2 requires ext-bcmath * -> the requested PHP extension bcmath is missing from your system.
Problem 3
- Installation request for nfq-alpha/sprite-bundle dev-min-image-fix -> satisfiable by nfq-alpha/sprite-bundle[dev-min-image-fix].
- nfq-alpha/sprite-bundle dev-min-image-fix requires ext-gd * -> the requested PHP extension gd is missing from your system.
Problem 4
- Installation request for zendframework/zend-ldap 2.5.1 -> satisfiable by zendframework/zend-ldap[2.5.1].
- zendframework/zend-ldap 2.5.1 requires ext-ldap * -> the requested PHP extension ldap is missing from your system.
I'm not sure how php composer
package system works, but when I tried adding manually missing packages, it had no effect.
Seems like that alpine OS
packages are missing (or there were never compiled for that OS). Most likely the best way to do installation is to use clean ubuntu image
or ubuntu + php7
, then install missing packages:
sudo apt-get install php7.0-gd
sudo apt-get install php7.0-intl
sudo apt-get install php7.0-xsl
and use it as builder.
At the moment I am working on a patch in my personal fork. Yesterday I successfully installed it but found that the GitHub Packages docker system does not provide anonymous access to public packages (See this discussion). So I need to rework things a bit.
There are still some open things to do but especially I do not (yet) have a database dump to import in case of development to have some dummy entries.
I managed to get "something" running. As soon as I commit something to my master
branch or add any tag, a new build is triggered. This time I use dockerhub as it allows everyone to download the generated images without any credentials.
@dromer Do you prefer to have a clean history in a potential PR or are you going to squash anyways? Otherwise I have to rework my branch history :smirk:.
Depending on the amount of lines we can squash it (if it's just a concise config or 2 that would be fine). Separate Dockerfile.yml and docker-compose.yml would be nice.
I opened PR #1088. However, I need #1085, which is thus a subset of #1088.
You might want to have a look at the PR and tell me if you are willing to squash or if I should rework the history.
Depending on the amount of lines we can squash it (if it's just a concise config or 2 that would be fine). Separate Dockerfile.yml and docker-compose.yml would be nice.
No squash is needed - rather use multi-stage builds
@shafr we where talking about git commits. and also I don't see how multi-stage Dockerfile is relevant here.
@Drachenkaetzchen To have a more detailed docker image, I'd like to add quite some testing data there. Would you be ok, if we added the test data from the demo page there? Of course, we would remove your personal account from the SQL dump to avoid any leaking of password hashes and replace it by something general (that can be published).
The demo site is already cleaned out of personal data I think. Do you have access to the dump?
Unfortunately neither to the SQL dump nor to a file system dump of the data
folder. Otherwise, I would have added these as example data in the docker PR. Are these large? Maybe you can send me the dumps? If required, I can send you a link to my personal NextCloud instance so no big mails need to be sent around.
Here are the sql dump and the data files: https://cloud.drachenkatze.org/index.php/s/6WJWp9t9qRqwzrx
Thank you, I downloaded the files. Are you keeping the link open in the future? Otherwise you can close it now.
No, I don't have a huge amount of disk space so I'll remove it now.
@christianlupus Did you succeed in making a working docker image?
@Boldie At the moment there is #1088 that goes into this direction. You can check out the relevant commits and use them my temporarily merging (locally) with your dev branch. Unfortunately, I am a bit short of thime these days. There are some edges and I might need to work over it once again.
We shall provide an easy to use environment and also a reference environment to support testing and developing. Common used tasks shall be made easy accessible for e.g. using a shell script or similar thing. For e.g. the following stuff shall be possible:
I suggest to make a docker container for this stuff.