Closed frimdo closed 7 years ago
Hey, @frimdo! I would put the entire phpci code inside a volume mounted into the container. That way you can simply destroy the container and rebuild it without issues. Also, if you follow the Docker advice and use one service per container you wouldn't even need to recreate the MySQL container either because that will be a separate container. You can check out my repo for Dockerizing a PHP app. Hope it helps.
Yeah - I have a separate DB :-) ... So you think making all of the /var/www/html volume is a good way? What if I wanted to update the system just by creating a newer version of docker image and "replace" the old one without touching settings? That would not work, since the old version would be injected with the settings...
Sorry, @frimdo ! I kind of lost you there. I'm not sure I understood your problem correctly. The advantage with the approach I mentioned is that having the code outside of the container, no matter how many time you create/destroy/upgrade the container or the image that the container is built upon, all your code and configuration is on the host machine. As long as you don't exec into the container and change files that are outside of the mounted volumes you shouldn't care about the container.
For example: if you mount your host path: '/home/user/project/phpci' into the container as: '/var/www/phpci' whenever you (re)create the container the files under '/home/user/project/phpci' will not be changed. I hope this clarifies a bit more the issue.
Well... no :D The thing is, that you and me, we are approaching differently to this problem. What I want (ideally) is having data (archived projects, configs, states,...) volumed out of container, but having the app data still caged inside container.
Your approach is possible, offcourse, but the problem appears when update of phpci is released. In your case you would have to exec into some running container and update manually (which would update files in volume) and you would be happy with your new version. But when you wanted to start a fresh new phpci instance, you would have the old version (until you would exec into container and updated it manually).
Updating PHPCI when creating a blank container is not solution as well, because I can not ensure stability of such app.
So what I would like to achieve, is: When a new PHPCI version is released, I test it, I find out how to use "old" config files and stuff, than create docker image with new PHPCI version and just run docker service update phpci --image phpci:latest
Hope I explained what I am trying to achieve...
So my question is: What directories should I backup in order to backup only configs, archived projects,... and left the app files untouched?
Ok. As I understand it you have exactly backwards and I strongly suggest reviewing the Docker docs on how Docker volumes work.
Before that let me just try one more time to clarify:
What I want (ideally) is having data (archived projects, configs, states,...) volumed out of container
You can do that perfectly easy. Just bind-mount the projects/configs folder/file from the host to the container. You can bind-mount any file or folder from the host to the container when you create the container.
but having the app data still caged inside container.
Again this is very easy to do. When building your image copy the PHPCI files into the Docker image. Then, when creating the container you can bind-mount ONLY those files and/or folders that you mentioned as described above.
In your case you would have to exec into some running container and update manually (which would update files in volume)
Here is the first time you understood me wrong :) . In the case I proposed, where the entire PHPCI folder is bind-mounted from the host to the container, you will NOT need to connect to the container to access any of its files. You will be able to just update to any version, make any modifications WITHOUT connecting to any running, or even stopped for that matter, container.
The following sentence
I would put the entire phpci code inside a volume mounted into the container.
means that your files are stored on the HOST and bind-mounted into the container. It is by NO means meant that the PHPCI files are "backed" into the Docker image as you suggest.
But when you wanted to start a fresh new phpci instance, you would have the old version (until you would exec into container and updated it manually).
This sentence puzzles me. If I understood you correctly, then I would say again that your statement is in error. Having the files on the HOST and NOT in the Docker image will mean that each time you create a new container from that image and bind-mount the same path on the HOST you will have access to the EXACT last version of the files you used.
So what I would like to achieve, is: When a new PHPCI version is released, I test it, I find out how to use "old" config files and stuff, than create docker image with new PHPCI version and just run docker service update phpci --image phpci:latest
And now I'm completely confused. In your previous statements you mentioned that exactly this usage scenario is not what you would like. And I get this idea from these statements:
you would have to exec into some running container and update manually .... when you wanted to start a fresh new phpci instance, you would have the old version (until you would exec into container and updated it manually).
So, at this point I am really confused of what you are trying to achieve. First, you are saying that you don't want to have to exec inside a container to update the PHPCI or have an older version of PHPCI when creating a new container, but then you mention that you want to create a Docker image with a specific version of PHPCI and use that image for creating containers. Let me try and explain how Docker images work with a short example:
To try and answer your question, I would do the following:
This time I really hope I nailed the explanation because I do not know if I can be any more explicit than that. :)
OK - I understand and the way you described is probably working. But it is not the solution I am looking for. So just simple question: where are config files? I mean all files needed to restore your setup.
/var/www/html/PHPCI/build/
find . -mmin -5 -print
after editing some of those settings, creating new projects, etc., but I found only my testfile to test the find command.Ok - let me reformulate my question once again... What I need to do, is to install new phpci instance, connecting to old database.
Use case:
When my container fails for whatever reason, I need to create a new container that instals itself in a way that the old database will be connected and unchanged. Right now, when launching a new container I run ./console phpci:install --url...
But this gives me integrity error, because phpci:install
tryes to rewrite old configuration. I found other commands, like phpci:run-builds, phpci:rebuild, phpci:update ...
but did not find any informations about them.
Any ideas?
...So there is no way to sort of connect to existing database?
More question than issue: I am trying to run PHPCI in docker. There are no problems with it, but when my container dies, I must run a new one and set everything up manually. My question is: what files should I put to volume, so I could run another instance from ti?
Question reformulated for non-docker: If your server running PHPCI died, and you were installing a new server - what files would you need from old server to restore old settings and all without any work?