3

The question is marked in bold if you wish to skip the explanation of our situation.

I work as a developer for a server network. We deploy multiple instances of our servers. we have 5 types of server types, and between 3-5 instances of each. We use a standalone server with an API for developing add-ons. Each server type has a different set of add-ons that are required.

Currently we're using a folder structure and running the instances manually, as such:

/servers
    /server1
        /instance1/.
        /instance2/.
    /server2
        /instance1/.

etc...

Each of these instances have a folder named module\ and inside of this folder we have our jar files (the system runs on Java)

Every time our add-on updates, we need to copy it into all instances of the servers that add-on is required on. We want to use symbolic links (ln -s ) and store only one instance of each add-on. This would be ideal, except for the fact that we want to move to virtual instance managing. We've sorted through several options and Docker seems to be the one that fits our needs best, with it's built in load-balancing system.

Most virtual platforms also virtualize the file-system, for example most virtual machines will create a file that contains all information about the file.

The question here is, does Docker virtualize the file-system, or does it mount the instance from the native Ubuntu file-system? I'm aware that Docker uses LXC when available, however I'm not very familliar with how LXC works and if symbolic links can work between instances If it does virtualize then that obviously means sym-links will not be an option. If this is the case then we wouldn't end up using Docker, because for efficiency, systems that save the file-system to a single file or a set of files also increases the amount of writes to the hard-drive, as the file needs to be re-written for any change, and the server instances could be quite large (multiple GB).

Improve this question
3
  • If using LXC, check out lxc.mount.entry and friends in lxc.container.conf(5). However, Docker now has its own library which it uses instead of LXC, from what I understood. Don't use symlinks, use bind-mounts (on folders) in such cases.
    – 0xC0000022L
    Jun 1, 2015 at 17:39
  • It states directly in the Docker documentation that Docker uses LXC. I do not understand what you mean by check out lxc.mount.entry, I'm not completely used to Linux machines.
    – D3_JMultiply
    Jun 1, 2015 at 17:42
  • you might want to update your documentation. Since version 0.9 Docker uses libcontainer as the default driver, when before it was using the LXC (liblxc) driver. The underlying container technology on the kernel side is the same. But if your Docker instance makes use of libcontainer, don't expect liblxc configuration stanzas to work. Also I quite explicitly referred to the man page in my comment: lxc.container.conf(5).
    – 0xC0000022L
    Jun 1, 2015 at 18:42

2 Answers 2

Reset to default
2

I am not sure whether I understood correctly your problem, but with Docker you can mount a directory from the host system inside the filesystem of the guest/virtual system. You can mount the same directory from host to several guest systems. You can find more detailed information here: https://docs.docker.com/userguide/dockervolumes/

It should work like this:

docker create --name=instance1 -v /home/shared/addon/:/usr/local/addon/:ro ...
docker create --name=instance2 -v /home/shared/addon/:/usr/local/addon/:ro ...
docker create --name=instance3 -v /home/shared/addon/:/usr/local/addon/:ro ...

Here /home/shared/addon/ is shared among the instances, inside each instace it can be accessed at /usr/local/addon/, and instances can only read it (ro). You don't even need ln -s.

This is only one possible way to do it, in the docs there are more advanced options.

Improve this answer
5
  • What I am asking if if I have a file in /home/shared/addon/ If an instance of Docker can access that file. We want to have multiple instanced of Docker running, all referencing the same addon so that we only need to have one copy of the addon on our server to reserve disk space. The addon is simply a .jar file that is loaded into the Java Classpath via a custom loader.
    – D3_JMultiply
    Jun 1, 2015 at 17:26
  • 1
    That is perfectly possible. You can share /home/shared/addon/ among different docker instances, and even make it read-only for them.
    – dashohoxha
    Jun 1, 2015 at 22:09
  • Thank you very much. Would it work via 'ln' or would I be required to use some other form of sharing them. I'm sure we'd figure it out once we set the system up, but we're just making sure that it will work for what we need before actually deploying it. Accepted your reply.
    – D3_JMultiply
    Jun 2, 2015 at 4:29
  • I have updated the answer above, because it is a bit long to describe in a comment.
    – dashohoxha
    Jun 2, 2015 at 7:56
  • Thank you very much, that is exactly what I was hoping for, that makes everything simple.
    – D3_JMultiply
    Jun 4, 2015 at 17:43
1

Let me share my experiences here. Docker does not seem to handle symbolic links well. I mounted my real directory to my container director the usual way (EXTERNAL_DATA is a environment variable for clarity: say /data/projectA):

-v $EXTERNAL_DATA:/docker/data

I have a symbolic linked file if you look from an external view is

symlink_file -> /data/projA/somereal_file.txt

When you go in the container, the ls command will show it exactly if you have typed the command outside the container. The somereal_file.txt is in the same directory as the symlink_file

You can access the real file but you will get an error if you try to use the symbolic link. 

head symlink_file
head: cannot open 'simlink_file' for reading: No such file or directory

I discover this when migrating one of my app to the docker container. Not sure this is a design flaw of docker or there are ways around this without rewriting original the application to deal with this special situation. Even you can alter the app, this is not the best way to deal with this problem.

Should we call this the fundamental symbolic link flaw of docker?

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .