I run Joomla image with :
docker run --name some-joomla --link test-mysql:mysql -p 8080:80 -d joomla
How can I change Joomla files ?
I think it is possible when specifying volume mapping, but I did not use that to run Joomla: is there a way to access Joomla files now ?
If I understand your question correctly, this thread should help you out.
Commit your container and create a new image from it.
Run a container from your just created image (and add the volume you need). Watch out for the port mappings, you either have to use other ports temporarily to check functionality of your new container, or you do step 3 beforehand.
If all works out, stop the old one.
If you want to check what's currently in the container, you can jump into it by running docker exec -it some-joomla bash (or sh, whatever Shell is installed in this image). You can then look for the files you want inside the container.
If you found them and you want to copy them on your local machine, you can run docker cp some-joomla:/your/path /path/on/local/machine.
Related
I need to work with all the files from a docker container, my approach is to copy all the list of files from the container to my host.
I'm using the next docker commands, for example with the postgres image:
docker create -ti --name dummy_1 postgres bash
docker cp dummy_1:/. Documents/docker/dockerOne
With this I have all the container folders and files in my host.
And then the idea is to transverse all the files with the java API, and work with them and finally delete the files and folders from local, but I would like to know if is it a better approach, maybe with Java and access directly to the container files, instead of create a local copy of the container files in my host.
Any ideas?
You can build a small server app inside your docker container which feeds you the information you need at an exposed port. Thats how i would have done it.
Maybe I don't understand the question, but you can mount a volume when you run, not create the container
docker run -v /host/path:/container/path your_container
Any code in the container (e.g. Java) that modifies files at /container/path will be reflected on the host, and not need to be copied back in/out. Similarly, any modifications on the host filesystem will be seen in the container.
I don't think I can implement an API in the docker container
Yes you can. You bind a TCP port using -p flag
I'm fairly new to using Docker and Docker Compose (using Docker Compose for this particular problem). Here is what I know so far about the problem I am facing: When using volumes when there are contents available in the host folder as well as the container's folder, the files inside the container's folder are hidden and the host's files are then made available to the container.
I want to use it the other way round. I would like to make available the container's files (that were copied into the image in the Dockerfile) to the host folder.
Is there a way to do that?
Here are a bunch of screenshots of my Dockerfile and Docker Compose to show my setup.
Dockerfile Screenshot
DockerCompose Screenshot
Thanks in advance! :)
I've come across the same thing many times and the way I go about it is as follows.
As the host volume will always take priority over the container filesystem, you have to copy the files out of the container to the host first, then volume mount them back - this way you get what was there originally, and also what might change in the future (by the container).
The following is all pseudo code, but should hopefully simulate the concept:
First run the main container:
docker run --rm -d --name my-container registry/image-name
Then copy the files you want from it to the local filesystem
docker cp my-container:/files/i/want ./files
Then stop the original container
docker stop my-container
Then mount them back into the container on the next run
docker run --rm -d --name my-container -v ./files:/files/i/want registry/image-name
Obviously you've mentioned compose there also, so just reflect the volume mapping into the compose format - the copy stuff will need to be done via standard docker however in line with the above.
Note: I wrote the above commands blind, but will check them over at lunch and correct any mistypes - but the concept is correct
I'm running the official solr 6.6 container used in a docker-compose environment without any relevant volumes.
If i modify a running solr container the data survives a restart.
I dont see any volumes mounted and it works for a plain solr container:
docker run --name solr_test -d -p 8983:8983 -t library/solr:6.6
docker exec -it solr_test /bin/bash -c 'echo woot > /opt/solr/server/solr/testfile'
docker stop solr_test
docker start solr_test
docker exec -it solr_test cat /opt/solr/server/solr/testfile
Above example prints 'woot'. I thought that a container doesnt persist any data? Also the documentation mentions that the solr cores are persisted in the container.
All i found, regarding container persistence is that i need to add volumes on my own like mentioned here.
So i'm confused: do containers store the data changed within the container or not? And how does the solr container achive this behaviour? The only option i see is that i misunderstood peristence in case of docker or the build of the container can set some kind of option to achieve this which i dont know about and didnt see in the solr Dockerfile.
This is expected behaviour.
The data you create inside a container persist as long as you don't delete the container.
But think containers in some way of throw away mentality. Normally you would want to be able to remove the container with docker rm and spawn a new instance including your modified config files. That's why you would need an e.g. named volume here, which survives a container life cycle on your host.
The Dockerfile, because you mention it in your question, actually only defines the image. When you call docker run you create a container from it. Exactly as defined in the image. A fresh instance without any modifications.
When you call docker commit on your container you snapshot it (including the changes you made to the files) and create a new image out of it. They achieve the data persistence this way.
The documentation you referring to explains this in detail.
There is something I'm missing in many docker examples and that is persistent data. Am I right if I conclude that every container that is stopped will lose it's data?
I got this Prestashop image running with it's internal database:
https://hub.docker.com/r/prestashop/prestashop/
You just run docker run -ti --name some-prestashop -p 8080:80 -d prestashop/prestashop
Well you got your demo then, but not very practical.
First of all I need to hook an external MySQL container, but that one will also lose all it's data if for example my server reboots.
And what about all the modules and themes that are going to be added to the prestashop container?
It has to do with Volumes, but it is not clear to my how all the the host volumes needs to be mapped correctly and what path to the host is normally chosen. /opt/prestashop er something?
First of all, I don't have any experience with PrestaShop. This is an example which you can use for every docker container (from which you want to persist the data).
With the new version of docker (1.11) it's pretty easy to 'persist' your data.
First create your named volume:
docker volume create --name prestashop-volume
You will see this volume in /var/lib/docker/volumes:
prestashop-volume
After you've created your named volume container you can connect your container with the volume container:
docker run -ti --name some-prestashop -p 8080:80 -d -v prestashop-volume:/path/to/what/you/want/to/persist :prestashop/prestashop
(when you really want to persist everything, I think you can use the path :/ )
Now you can do what you want on your database.
When your container goes down or you delete your container, the named volume will still be there and you're able to reconnect your container with the named-volume.
To make it even more easy you can create a cron-job which creates a .tar of the content of /var/lib/docker/volumes/prestashop-volume/
When really everything is gone you can restore your volume by recreating the named-volume and untar your .tar-file in it.
I created a data only container containing static HTML files that are intended to be consumed by a nginx container. Goal is that my webapp is providing a volume that nginx can use.
For this reason I created a simple Dockerfile:
FROM scratch
MAINTAINER me <me#me.com>
ADD dist/ /webappp/
When I run the created container from command line run -d -v /webappp --name webapp myOrg/webapp echo yo
I get the error Error response from daemon: Cannot start container db7fd5cd40d76311f8776b1710b4fe6d66284fe75253a806e281cd8ae5169637: exec: "echo": executable file not found in $PATH which if of course correct because the image has no commands at all the can be executed. Running a container without a command is not possible.
While this error on command line is not a big problem for me because I know the data container is still created and can now be accessed by nginx it turns out to be a no go if I want to automate it with Vagrant. The automated processes always fail because of this error.
My only solution so far is to extend my little handy image from from a distro which IMHO doesn't make sense for a data only container in order just to call echo or true!
Is there a NOP exec command in docker or does docker need always to execute something, is it possible to run a scratch container that does nothing or does not produce an error.
As mentioned in the Docker manual: The container don't need to be running. It also doesn't say that the container "should" be able to run at all.
So instead of echoing something stupid by running a data only container e.g. docker run -v /webappp --name webapp myOrg/webapp echo yo
It is already enough to just create the container and never run/start it.
docker create -v /webappp --name webapp myOrg/webapp
Note to self: Vagrant does not support docker create when provisioning!
Why are you using scratch?
Just use the nginx image as a base. You already have the image cached so it won't take up any more space and you'll be able to call echo.
Some references for data containers:
Data-only container madness
Understanding Volumes in Docker
Offiical docs on data containers