Is a Volume Needed?

[jeden25]

Drupal would require some local storage for images and the like, right? So in order for the container to be persistent wouldn't I need to include a volume as well as the database?

If it is needed, I'm confused as to why the official Wordpress Dockerfile specifies a volume while the official Drupal Dockerfile does not?

[jonpugh]

Yes, this is the main problem with this image. There should be a volume for the source code files as well so we can add our own Drupal codebase.

Drupal core by itself isn't going to cut it for most people.

[yosifkit]

A VOLUME line is not necessary in the Dockerfile for --volumes-from or -v to work (yes, you would need a -v on the first container for --volumes-from to work to a second container), so docker run -v /local/images/path/:/drupal/path/to/images/ drupal will work fine But if you have a place that you think a VOLUME should be defined, a PR is welcome.

[tianon]

Yeah, this one was a hard one for me since from what I understand, the "sites" directory is probably the best place for the volume to be, but it must be pre-seeded with the initial content or Drupal won't start up. I'd love to see this fixed somehow.

[skyred]

D8 uses a different structure now. For example, contributed modules are downloaded at /modules/, unlike D7, contributed modules are located in /sites/*/modules/

I was thinking the same question. But, there are different ways people would use this image. For example, I can potentially use a docker d8 image for

1. spin up sandboxes for testing. Then, I don't need Volume.
2. start a new project. Then, I want the whole Drupal directory to be managed by Git (except user files). It doesn't matter D7 or D8, it's best practise to put the whole Drupal directory under Git. If we put the while Drupal directory in a Volume, then we don't we just use PHP container and a Data container to start with?

[alexanderjulo]

In my opinion we do need volumes, so that this image is actually usable. We should define mount points for the following directories (in D8):

• /var/www/html/modules
• /var/www/html/profiles
• /var/www/html/themes

These three are no-brainers, they are empty by default (besides a README.txt) and will ensure that the container can be upgraded by just bumping the image version.

We should also include /var/www/html/sites/default/files, which will make sure user content survives.

Much more difficult is the question on how to deal with settings.php and default.settings.php. From what I understand we can not just define volumes on these files, as docker would just overwrite them with directories and the drupal install expects them to be files in a certain state with a certain content.

I'd be interested in any ideas. If we just mount /var/www/html/sites/ or a subdirectory we also have the problem that the structure is lost and drupal will either not install at all or refuse installation.

[alexanderjulo]

Actually, scratch that, you don't need it. You can run this fine without any volumes, by using a drupal:8 as the image for the storage, too. See the following docker-compose.yml for an example. This also fixes issues with settings.php and so on. We can bump the image for drupal without bumping storage-drupal:

drupal:
    image: drupal:8
    volumes_from:
        - storage-drupal
    links:
        - "db:mysql"
    ports:
        - "80:80"
db:
    image: mysql
    volumes_from:
        - storage-mysql
    environment:
        - MYSQL_USER=someuser
        - MYSQL_PASSWORD=thispasswordsucks
        - MYSQL_DATABASE=somedb
        - MYSQL_ROOT_PASSWORD=thispasswordsuckstoo
storage-drupal:
    image: drupal:8
    volumes:
        - /var/www/html/modules
        - /var/www/html/profiles
        - /var/www/html/themes
        - /var/www/html/sites
storage-mysql:
    image: mysql
    volumes:
        - /var/lib/mysql

[eduarddotgg]

Volume for Drupal's root folder would be great!

[alexanderjulo]

Then you could not upgrade anymore by upgrading the container, because the drupal core folder would be in the volume.

On 14 Nov 2015 21:46 +0100, admdhnotifications@github.com, wrote:

Volume for Drupal's root folder would be great!

—
Reply to this email directly orview it on GitHub(#3 (comment)).

[eduarddotgg]

oh, i see. than this folders would be great:
/var/www/html/modules
/var/www/html/profiles
/var/www/html/themes
/var/www/html/sites/default/files
that @alexex mentioned before

[aborilov]

Can't use this image with kubernetes, because after every restart, installation process start again.

[juliencarnot]

Interesting issue&thread! As a newcomer to Docker, I've been struggling to find definitive answers on data/volumes/volume containers management for drupal, let alone some kind of benchmark of the different options, so it's quite difficult to determine which one would apply better to my usecase... If there's some consensus, adding some pointers on the description page would be great!

[aborilov]

The problem is that there are no docker-entrypoint.sh, which have to copy /var/www/html to volume, if it is empty, like it does in WordPress Dockerfile.

[YvanDaSilva]

@alexex Your solution does fix the issue of upgrading to a new version.
However what it does not fix, is the ability to sync your data with the host.
"/var/www/html/sites" Can't still be mounted from host as they contain default settings that drupal wants.

So you are still prone to loose your data by removing the data container, or in the case of k8s users like in the previous comments loose your pod and by so loose your data.

Something still needs to be done here, so that drupal does become a real containerized application that can survive: stop & destroy

Update: Just noticed that on your example your are using for your storage ambassador container mariadb and drupal images and you are not passing a command to execute. This would have for effect to keep these containers up. It is a good idea to use the same images though, as those are already pulled and would not need extra space.
You can change this by adding -> command: bash or using another image (busybox for example)