ciao @samos123,

for a few days, there's an official Drupal-image in the docker-library. however it hardly has the capabilities of this one here.

i'm thinking about offering all features from here there. if they get accepted, and makes this image superfluous, that would be much less maintaining.

what ya think?

Not sure it can be labeled as an issue as this can be a design decision but just FYI.

I use drush_make to download all the required modules,
I usually do that at build time in the Dockerfile.

With the previous version of your image, it used to work because you did not set any VOLUME.

With your new version it doesn't work anymore as any changes operated on the folder set as a volume is applied to the container filesystem and thus discarded at run time.

Personally I think that the VOLUME decision should be handed the end user. In my case it breaks what used to work.

Thanks for the image. Let me know.

hey @samos123, i've updated the master-branch to Drupal 7.36.

since this is not a security-update and can potentially break instances (though not drastically), i propose to keep the 7.35-image also in the registry until a new security-related release is published.

i think it would be nice to enable the users to simply auto-install a set of modules when a fresh site is created.
the list of modules would be read from /contrib/modules.txt and an (csv-)environment variable.

i never used the features-module. but maybe that could be considered as well.

I already got it working. I will test it tomorrow again and push then.

i'm not completely decided to an opinion on that:

using the drush cron command has the advantage that no user will be confronted with longer loading times when he/she has the luck to trigger the "Poor man's cron". some people insist on not using the latter one (performance fans). but with the image this could only be achieved with a host-cron that will trigger a drush cron with docker exec. not all of the possible users have access to the host system.

by using supervisord to run Apache and Cron simultaneously in one container, this could be solved. Cron will then trigger a drush core-cron.

of course this could be done with a derived image as well. but you know, i'm a friend of good defaults for accessibility. another solution could be to offer such images with a tag like :7.35-cron.

i'm looking for your feedback on this.

if there is some consent on implementing this, should the interval of the cron be configurable with an environment variable? e.g. CRON_RUNS_PER_DAY.

as the image doesn't rely on tutum's php-image anymore, the name of the repository is a bit of misleading and outdated. i propose to name the github-repo and the Docker-image identically for clearness. as Drupal 8 comes closer, i'd also include an explicit reference to the major version. some thoughts:

• drupal7
• drupal-7
• drupal-seven

(nothing really sexy, but well.)

github will automaticall redirect to the new repository. anyone knows how the docker-registry handles this?

Hi Samos,

Here is an example of your docker drupal in combination with the default docker mysql
to be used with fig. Hope you will add this to your readme file.

Just create fig.yml and run fig up and everything should be starting automatically.

fig.yml file:

drupal:
  image: samos123/drupal
  links:
    - db:db
  ports:
    - "80:80"
  environment:
    DB_USER: root
    DB_PASS: supersecretpassword

db:
  image: mysql
  ports:
    - 3306
  environment:
    MYSQL_ROOT_PASSWORD: supersecretpassword

i have no concrete concept for this, but some thoughts on a way to restore the content and configuration of another instance in a fresh container. it aims to be a simple backup-helper and help pulling the state of a production-instance to a development-environment.

• it could rely on Backup and Migrate
• it looks for backups in /var/www/private/backup and /backup for the latest backup by default while the latter mountpoint precedes
• later it may restore one of several backups selected by timestamp and relative by counting from the last backup
• it would be called by docker run/exec <container> restore [[args]] or invoked on run if a configuration environment is set
• it may have a backup-counterpart

any fresh thoughs are appreciated.

(be aware that a fully supported docker cp is coming. 😃)

Hi, I'm trying to link my remote SQL DB to your drupal image using environment variables.

I'm typing in this into the Windows 7 cmd (I'm using boot2docker):
docker run --name sackman -e DB_HOST=[redacted] -e DB_NAME=[redacted] -e DB_USER=[redacted] -e DB_PASS=[redacted] -p 80:80 samos123/drupal

I don't think the error is related to connecting to my DB because I get this nice message:
=> Skipped creation of database ad_09b445d92a5cc19 - it already exists.
(when I type in incorrect creds, I get an authentication error)

However, After the above message, I get the following error message:
find: ./*/files': No such file or directory`

Then, the container immediately stops. The logs show the same messages as above. Any thoughts?

See https://www.drupal.org/PSA-2014-003 - this needs updating :) thanks +1

i'm quiet confused atm. yesterday evening the commit that introduces the php:apache-image as parent played nicely.
today i noticed it fails when drush shall install the new site:

web_1 | WD system: update module enabled. [65.48 sec, 23.97 MB]                   [info]
web_1 | WD user: Session opened for admin. [65.91 sec, 24.1 MB]                 [notice]
web_1 | sh: 1: -t: not found
web_1 | WD mail: Error sending e-mail (from [email protected] to                 [error]
web_1 | [email protected]). [73.23 sec, 23.94 MB]
web_1 | WD cron: Cron run completed. [73.3 sec, 23.93 MB]                       [notice]
web_1 | Installation complete.  User name: admin  User password: changeme           [ok]
web_1 | [73.45 sec, 23.92 MB]
web_1 | Returned from hook drush_core_site_install [73.45 sec, 23.92 MB]         [debug]
web_1 | Unable to send e-mail. Contact the site administrator if the problem     [error]
web_1 | persists. [73.45 sec, 23.92 MB]
web_1 | Command dispatch complete [73.45 sec, 23.89 MB]                         [notice]
web_1 |  Timer                Cum (sec)  Count  Avg (msec) 
web_1 |  page                 73.053     1      73052.72   
web_1 |  drupal_http_request  0.838      1      838.15
web_1 | Peak memory usage was 26.25 MB [73.46 sec, 23.89 MB]                    [memory]

as this discussion implies sendmail must be present when installing a site. since it doesn't seem to be a bad idea to have it on board, i installed it. with no luck.

again, i'm confused. i never came across that kind of question before when i tweaked around.

i also tried it with 6.4.0 of drush.

can you please test a build?

i also wonder why there was a second, identical commit created when i clicked the merge-button on this website. (fc17031)

This module looks interesting regarding that enhancement.

there are some needs for updates on the Docker Registry page:

• version 7.37 is still not available
  • last build was on 10th of April
• description says the same
• could you add a word about Drush and maybe the bootstrapping in the description?

my repo builds fine after pushing to github, so there seems to be an issue with your settings

DRUSH_VERBOSITY and DRUSH_DEBUG, both defaulting to 0

In f33e2dd the (admittedly ugly) postgres query I'd written:

drush sql-query --result-file='table-query.txt' '\dt';
lines=$(wc -l table-query.txt | sed 's/ .*//g')
if [[ $lines -eq 0 ]]; then
    run_scripts setup
else
    echo "=> Skipped setup - table drupal already exists."
fi

was changed to:

drush sql-query '\l' > /dev/null || TABLE_EXISTS=$?

which does not have the desired effect. That escaped my notice, I didn't test well enough/review closely enough. (That's on me, my bad.) That will (just about) 100% of the time exit 0, and doesn't answer the question which really needs to be asked.

Running that in an empty postgres container:

root@7ac75f356aa0:/# psql -U postgres -c '\l'
                                 List of databases
   Name    |  Owner   | Encoding |  Collate   |   Ctype    |   Access privileges   
-----------+----------+----------+------------+------------+-----------------------
 postgres  | postgres | UTF8     | en_US.utf8 | en_US.utf8 | 
 template0 | postgres | UTF8     | en_US.utf8 | en_US.utf8 | =c/postgres          +
           |          |          |            |            | postgres=CTc/postgres
 template1 | postgres | UTF8     | en_US.utf8 | en_US.utf8 | =c/postgres          +
           |          |          |            |            | postgres=CTc/postgres
(3 rows)

you see the default database that's part of the base image (could be named something other than postgres via an undocumented environment variable), and the two templates which are always there.

According to the postgres docs:

\l[+] or \list[+] [ pattern ]
List the databases in the server and show their names, owners, character set encodings, and access privileges. ...

Postgres functions fundamentally differently to mysql. As mentioned in #23 (comment) the better analogue to mysql databases is postgres schemas, whcih can be queried via \dn:

root@7ac75f356aa0:/# psql -U postgres -c '\dn' 
  List of schemas
  Name  |  Owner   
--------+----------
 public | postgres
(1 row)

however, again, that will (just about) always exit successfully. The public schema is available by default. The change introduced in f33e2dd must be reverted if the drupal+chado is to function at all. It always returns 0, so the code assumes that "tables are found" even when they're not: (\dt actually checks for tables)

root@7ac75f356aa0:/# psql -U postgres -c '\dt' 
No relations found.
root@7ac75f356aa0:/# echo $?
0

Planned change

I plan to change this back to \dt and saving to a temporary file.

Proof that this is what's required if you really want to check for tables being there (which is an improvement over mysql)

root@7c4325ae33e4:/var/www/html# drush sql-query --result-file='table-query.txt' '\dt'
root@7c4325ae33e4:/var/www/html# if [[ -s 'table-query.txt' ]]; then echo "data"; else echo "empty"; fi;
empty
root@7c4325ae33e4:/var/www/html# drush sql-query 'create table test(id int);'
root@7c4325ae33e4:/var/www/html# drush sql-query --result-file='table-query.txt' '\dt' 
root@7c4325ae33e4:/var/www/html# if [[ -s 'table-query.txt' ]]; then echo "data"; else echo "empty"; fi;
data
root@7c4325ae33e4:/var/www/html# cat table-query.txt 
public  test    table   postgres

vs \l on a fresh database:

root@7c4325ae33e4:/var/www/html# drush sql-query --result-file='table-query.txt' '\l' 2&> /dev/null 
root@7c4325ae33e4:/var/www/html# echo $?
0
root@7c4325ae33e4:/var/www/html# cat table-query.txt 
postgres        postgres        UTF8    en_US.utf8      en_US.utf8
template0       postgres        UTF8    en_US.utf8      en_US.utf8      =c/postgres
postgres=CTc/postgres
template1       postgres        UTF8    en_US.utf8      en_US.utf8      =c/postgres
postgres=CTc/postgres

Supporting information

MySQL aliases schema with database behind the scenes, such that CREATE SCHEMA and CREATE DATABASE are analogs. It can therefore be said that MySQL has implemented cross-database functionality, skipped schema functionality entirely, and provided similar functionality into their implementation of a database. In summary, Postgres fully supports schemas but lacks some functionality MySQL has with databases, while MySQL does not even attempt to support true schemas.

https://en.wikipedia.org/wiki/Comparison_of_relational_database_management_systems#Databases_vs_schemas_.28terminology.29