I would like create new volume in Portainer. So, in Volumnes page and Create Volume, i want add my /media/USBNAS to /media container folder :
Driver options
name : /media/USBNAS value : /media
But i've an error message with invalid option key: "/media/USBNAS"
There is something I'm doing wrong, but I do not know what
You will need the "local-persist" driver for this.
You can get it here: https://github.com/CWSpear/local-persist
Just install, if possible, using the install script and you're good to go.
Name needs to be "mountpoint" and value is your local path. As you setup your container, you can choose your created volume and set the container path.
Related
I saw this post with different solutions for standard docker installation:
How to change the default location for "docker create volume" command?
At first glance I struggle to repeat the steps to change the default mount point for the rootless installation.
Should it be the same? What would be the procedure?
I just got it working. I had some issues because I had the service running while trying to change configurations. Key takeaways:
The config file is indeed stored in ~/.config/docker/. One must make a daemon.json file here in order to change preferences. We would like to change the data-root option (and storage-driver, in case the drive does not have capabilities
To start and stop the headless service one runs systemctl --user [start | stop] docker.
a. Running the systemwide service starts a parallel and separate instance of docker, which is not rootless.
b. When stopping make sure to stop the docker.socketfirst.
Sources are (see Useage section for rootless)
and (config file information)
We ended up with the indirect solution. We have identified the directory where the volumes are mounted by default and created a symbolic link which points to the place where we actually want to store the data. In our case it was enough. Something like that:
sudo ln -s /data /home/ubuntu/.local/share/docker/volumes"
So my question is whether it is possible to have a volume like:
"${my_conf_file}:-raw.my/GitHub/file.git":/conf.json
So this would be my goal, however I do not find anything related to this. In the end if the user has a file, the file should be passed, otherwise either conf.json should not be replaced by anything (because the GitHub file is already there, to be replaced by a conf file that a user might have) or the file from GitHub should be passed again.
If it best to figure out the first part ("${my_conf_file}:-raw.my/GitHub/file.git") ahead of the docker run.
In your start script (which calls docker run or uses your docker-compose.yml), add a script able to determine which config file you want (the user's, conf.json itself or the one from GitHub)
Once you can script that, then you can add your docker run -v call, which will mount the right file to :/conf.json in the container.
I've been successfully run Ignite docker with parameter CONFIG_URI=https://raw.githubusercontent.com/apache/ignite/master/examples/config/example-cache.xml.
But I want to enable persistence and create a custom config file which I want to pass instead of CONFIG_URI.
Is there a way to pass a CONFIG file from host with the docker run command ?
On your Docker run command, you can use the -v parameter (or the equivalent in the Dockerfile) to map a local directory to that of the container.
Then you'd move your configuration file in there and set your CONFIG_URI to point to that, something like CONFIG_URI=file:///opt/etc/ignite.xml.
Of course you'll need to create a volume of some kind for the persistent files; you don't want to be storing them inside the container.
As antkr notes, if you're using Kubernetes, you can use a config map and StatefulSets, but you'd still need to set the CONFIG_URL in the same way.
Since you are going to use persistence, configure persistent volume according to following documentation:
https://kubernetes.io/docs/tasks/configure-pod-container/configure-persistent-volume-storage/
Mount it to your pod and read the configuration file from the volume using the CONFIG_URI parameter.
I am using Jupyterhub 0.9.4 with DockerSpawner.
My goal is to pass every container spawned by the Spawner an additional host name, so make an additional entry in /etc/hosts.
I first tried via my docker-compose.yml file, which does not work, as the container are created by Jupyterhub.
I also tried it in the Dockerfile itself, but there it got overwritten.
I further tried it with changes in the jupyterhub_config.py file, by adding:
c.DockerSpawner.extra_create_kwargs.update({'command': '--add-host="<ip-address> <hostname>"'})
Still I do not see an entry in the /etc/hosts file in the container.
Anyone has a clue where I have to add it?
Thanks,
Max
You can do the equivalent of docker run --add-host "foo.domain.local:192.168.1.12" ... like so:
c.DockerSpawner.extra_host_config.update({
"extra_hosts": {
"foo.domain.local":"192.168.1.12",
"other.domain.local":"192.168.1.13"
}
})
I couldn't find that in any documentation.
I'm having an issue with docker-compose where I'm passing a file into the container when it's run. The issue is that it doesn't seem to recognize when the file has been changed and serves the saved result back indefinitely until I change the name of the file.
An example (modified names for brevity):
jono#macbook:~/myProj% docker-compose run vpn conf.opvn
Options error: Unrecognized option or missing parameter(s) in conf.opvn:71: AXswRE+
5aN64mYiPSatOACC6+bISv8RcDPX/lMYdLwe8zQY6qWtbrjFXrp2 (2.3.8)
Then I change the file, save it, and run the command again - exact same output.
Then without changing anything I do this:
jono#macbook:~/myProj% cp conf.opvn newconf.opvn
And when I run $ docker-compose run vpn newconf.opvn it works. Seems really silly.
I'm working with Tmux and Mac if there is some way that affects it. Is this the expected behaviour? I couldn't find anything documenting this on the docker-compose homepage.
EDIT:
Specifically I'm using this repo from the amazing Jess.
The image you are using is using volume in order to mount your current directory. Basically the file conf.opvn is copied to the docker container.
When you change the file, the container doesn't see that change, but it does pick up the rename (which the container sees as a new file). This most probably is due to user rights of the file and the user rights of the folder in the docker container where this file is mounted. Try changing the file's permissions to 777 before beginning the process and check again.
You can find a discussion about this in the official forum of docker