geerlingguy / drupal-container Goto Github PK

If I run the command:

docker run -it geerlingguy/drupal:latest bash

And then run apt-get update in the container session I get this as a result:

Get:1 http://deb.debian.org/debian buster InRelease [122 kB]
Get:2 http://security.debian.org/debian-security buster/updates InRelease [65.4 kB]
Get:3 https://packages.sury.org/php buster InRelease [6837 B]
Get:4 http://deb.debian.org/debian buster-updates InRelease [51.9 kB]
Err:3 https://packages.sury.org/php buster InRelease
  At least one invalid signature was encountered.
Err:2 http://security.debian.org/debian-security buster/updates InRelease
  At least one invalid signature was encountered.
Err:1 http://deb.debian.org/debian buster InRelease
  At least one invalid signature was encountered.
Err:4 http://deb.debian.org/debian buster-updates InRelease
  At least one invalid signature was encountered.
Reading package lists... Done
W: GPG error: https://packages.sury.org/php buster InRelease: At least one invalid signature was encountered.
E: The repository 'https://packages.sury.org/php buster InRelease' is not signed.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.
W: GPG error: http://security.debian.org/debian-security buster/updates InRelease: At least one invalid signature was encountered.
E: The repository 'http://security.debian.org/debian-security buster/updates InRelease' is not signed.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.
W: GPG error: http://deb.debian.org/debian buster InRelease: At least one invalid signature was encountered.
E: The repository 'http://deb.debian.org/debian buster InRelease' is not signed.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.
W: GPG error: http://deb.debian.org/debian buster-updates InRelease: At least one invalid signature was encountered.
E: The repository 'http://deb.debian.org/debian buster-updates InRelease' is not signed.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.

When I was doing some testing today, for some reason the install of the dependency of drupal coder module was trying to use git instead of downloading the zip. And because git was not available, it failed.

So maybe install git? I hate adding more and more deps though.

The ARM build of this image doesn't have Composer... while the AMD64 build does.

It would be nice to have Composer available in both.

Can dig up the logs if additional information is needed. Was getting "The website encountered an unexpected error. Please try again later." when visiting cluster.pidramble.test.

It was a mysql connection error message - googling said to install php-mysql, and I saw that it was installed for php7.2

Tried to a2dimod php7.3 / a2enmod php7.2, except there wasn't a php7.2 apache module available.

I never really completed #1 ... I want to make it so, if there are database credentials provided, and an env variable like DRUPAL_INSTALL_IF_NOT_PRESENT is true, then we use Drush to install Drupal... maybe?

Basically, it would take another step out of the first-use/testing order of operations for this image. Mostly, I'm thinking of how it relates to the Raspberry Pi Dramble. Right now after setting everything up, you have to run through the Drupal installer via UI to complete the Drupal installation.

Not that that's horrible or anything, it just takes a little extra time, and isn't automatic. I hate things that aren't automatic.

If Drupal is already installed (or DRUPAL_INSTALL_IF_NOT_INSTALLED is set to false), then this new code that does the installation should not be run.

Hello @geerlingguy, I am working on a similar project during this Google Summer of Code community bonding period so that developers can easily test and review the project and it will easy for developers and users to deploy their Drupal site to any server through SSH using Ansible.
Link to the repo - https://github.com/dbjpanda/drupal-devops

This way the container can be scaled to more than 1 replica in Kubernetes (see geerlingguy/raspberry-pi-dramble#111), and it can also be replaced and still use an existing database.

Basically, the entrypoint script, if it needs to download the Drupal codebase, should also copy default.settings.php over to settings.php and append environment-variable DB connection information, like:

$databases['default']['default'] = [
  'driver' => 'mysql',
  'database' => getenv('DRUPAL_DATABASE_NAME'),
  'username' => getenv('DRUPAL_DATABASE_USERNAME'),
  'password' => getenv('DRUPAL_DATABASE_PASSWORD'),
  'host' => getenv('DRUPAL_DATABASE_HOST'),
  'port' => getenv('DRUPAL_DATABASE_PORT'),
];

I also need to do a site install and see what else is added to the default settings.php—I think it also drops some sort of encryption key in there. That should be set as an env variable as well, if that's the case, with instructions for how to generate it.

Since I hate seeing warnings on the site Reports page... it would be nice to be able to use an environment variable like DRUPAL_TRUSTED_HOSTS to drive an optional config section in settings.php to squelch the warning on the Reports page (and, well, for slightly improved site security!).

after running ansible and docker run I get erros in docker logs (macos m1):

2024-05-16 14:13:18 Removing any existing files inside /var/www/html...
2024-05-16 14:13:18 Downloading Drupal...
2024-05-16 14:13:39 Download complete!
2024-05-16 14:13:39 Configuring settings.php with environment variables...
2024-05-16 14:13:39 Correcting permissions on /var/www...
2024-05-16 14:13:47 chown: changing ownership of '/var/www/html/vendor/web.config': Permission denied
2024-05-16 14:13:47 chown: changing ownership of '/var/www/html/vendor/.htaccess': Permission denied
2024-05-16 14:14:52 AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 172.17.0.2. Set the 'ServerName' directive globally to suppress this message

Because I'm overwriting both sites-enabled and sites-available, the vhost can get double-replaced, resulting in something like:

DocumentRoot "/var/www/html/web/web"

When I set APACHE_DOCUMENT_ROOT=/var/www/html/web.

D'oh!

Drush site-install uses mysql on the CLI to create/empty the database during a site-install, and without it you get the error:

In SiteInstallCommands.php line 354:
                                                      
  Failed to create database: sh: 1: mysql: not found

See: geerlingguy/raspberry-pi-dramble#138

Trying to setup raspberry-pi-dramble on 4 rpi 4s. I have been successful in Provisioning the Pis up to the point where the drupal nodes get configured. The two drupal nodes are in "CrashLoopBackOff" status.

pi@kube1:~ $ kubectl get pods -A
NAMESPACE NAME READY STATUS RESTARTS AGE
default nfs-client-provisioner-7b57746cd-pg2n8 1/1 Running 3 27h
drupal drupal-54856bf894-rxckw 0/1 CrashLoopBackOff 19 79m
drupal drupal-54856bf894-vnxxc 0/1 CrashLoopBackOff 19 79m
drupal mysql-8bbdcb879-vbq8m 1/1 Running 3 27h
kube-system coredns-5c98db65d4-jbmhn 1/1 Running 4 45h
kube-system coredns-5c98db65d4-tkds6 1/1 Running 5 45h
kube-system etcd-kube1 1/1 Running 4 45h
kube-system kube-apiserver-kube1 1/1 Running 4 45h
kube-system kube-controller-manager-kube1 1/1 Running 4 45h
kube-system kube-flannel-ds-arm-4rh25 1/1 Running 5 45h
kube-system kube-flannel-ds-arm-777ks 1/1 Running 5 45h
kube-system kube-flannel-ds-arm-qn6rc 1/1 Running 2 27h
kube-system kube-flannel-ds-arm-tvhwj 1/1 Running 5 45h
kube-system kube-proxy-8dtck 1/1 Running 4 45h
kube-system kube-proxy-ksk4d 1/1 Running 4 45h
kube-system kube-proxy-wc8sx 1/1 Running 2 27h
kube-system kube-proxy-z72b6 1/1 Running 4 45h
kube-system kube-scheduler-kube1 1/1 Running 4 45h
kube-system metrics-server-f948cd54-wkzdk 1/1 Running 4 45h
kube-system traefik-ingress-controller-6zzzn 1/1 Running 3 27h
kube-system traefik-ingress-controller-pxhd2 1/1 Running 2 27h
kube-system traefik-ingress-controller-z82vm 1/1 Running 3 27h
registry docker-registry-7c68c86677-8rfcb 1/1 Running 3 27h

The problem seems to be with drupal/core 8.8.6 requiring ext-dom per the logs:

kubectl logs --follow pods/drupal-54856bf894-vnxxc -n drupal
Removing any existing files inside /var/www/html...
Downloading Drupal...
Download complete!
Configuring settings.php with environment variables...
Correcting permissions on /var/www...
Running composer install...
Loading composer repositories with package information
Installing dependencies (including require-dev) from lock file
Your requirements could not be resolved to an installable set of packages.

Problem 1
- drupal/core 8.8.6 requires ext-dom * -> the requested PHP extension dom is missing from your system.
- drupal/core 8.8.6 requires ext-dom * -> the requested PHP extension dom is missing from your system.
- Installation request for drupal/core 8.8.6 -> satisfiable by drupal/core[8.8.6].

To enable extensions, verify that they are enabled in your .ini files:
- /etc/php/7.4/cli/php.ini
- /etc/php/7.4/cli/conf.d/10-opcache.ini
- /etc/php/7.4/cli/conf.d/10-pdo.ini
- /etc/php/7.4/cli/conf.d/20-apcu.ini
- /etc/php/7.4/cli/conf.d/20-calendar.ini
- /etc/php/7.4/cli/conf.d/20-ctype.ini
- /etc/php/7.4/cli/conf.d/20-exif.ini
- /etc/php/7.4/cli/conf.d/20-ffi.ini
- /etc/php/7.4/cli/conf.d/20-fileinfo.ini
- /etc/php/7.4/cli/conf.d/20-ftp.ini
- /etc/php/7.4/cli/conf.d/20-gettext.ini
- /etc/php/7.4/cli/conf.d/20-iconv.ini
- /etc/php/7.4/cli/conf.d/20-json.ini
- /etc/php/7.4/cli/conf.d/20-phar.ini
- /etc/php/7.4/cli/conf.d/20-posix.ini
- /etc/php/7.4/cli/conf.d/20-readline.ini
- /etc/php/7.4/cli/conf.d/20-shmop.ini
- /etc/php/7.4/cli/conf.d/20-sockets.ini
- /etc/php/7.4/cli/conf.d/20-sysvmsg.ini
- /etc/php/7.4/cli/conf.d/20-sysvsem.ini
- /etc/php/7.4/cli/conf.d/20-sysvshm.ini
- /etc/php/7.4/cli/conf.d/20-tokenizer.ini
You can also run php --ini inside terminal to see which files are used by PHP in CLI mode.

Could this be related to geerlingguy/drupal-vm#1962 ? If so any ideas on how to fix?

Thanks

See how it's being done in the upstream geerlingguy/php-apache container image build process. Basically add the docker login details as protected env vars in Travis CI, then edit the .travis.yml file to do an automated push once the build is complete on the master branch.

See closed issue geerlingguy/php-apache-container#5 and downstream issue geerlingguy/raspberry-pi-dramble#119

Basically, I want to use this image on a Raspberry Pi, so I need a pi-compatible (arm32v7) image tagged. I would love to do a proper multi-arch image with all PHP versions, but that would be excruciatingly difficult to maintain correctly.

Therefore I'm thinking I'll do one Pi-based build (built on my Mac for now, but can also be built using QEMU and/or on a Pi directly) and tag it with :latest-pi or something like that.

TASK [Build the x86 Docker image from the main Dockerfile.] ********************
fatal: [localhost]: FAILED! => {"changed": false, "msg": "Failed to import the required Python library (Docker SDK for Python: docker (Python >= 2.7) or docker-py (Python 2.6)) on fv-az190-719's Python /opt/hostedtoolcache/Python/3.9.5/x64/bin/python. Please read the module documentation and install it in the appropriate location. If the required library is installed, but Ansible is using the wrong Python interpreter, please consult the documentation on ansible_python_interpreter, for example via `pip install docker` or `pip install docker-py` (Python 2.6). The error was: No module named 'six'"}

Lots of failed builds with the above. Not sure why, I do the install on the Actions CI environment with pip3 install ansible docker :/

Right now after #4 I will have three separate tags, one for amd64, one for arm64, and one for armv7... it would be nice to just have one latest tag for multiarch.

I recently pulled down the latest version of the docker image and xdebug is no longer working.

After some poking around inside the image, I found out that it's because the location of "xdebug.so" has changed.

In "/etc/php/7.4/mods-available/xdebug.ini", the "zend_extension" property is pointing to "/usr/lib/php/20170718/xdebug.so".

In the latest drupal image, it should be pointing to "/usr/lib/php/20190902/xdebug.so".

After a few restarts (e.g. docker stop && docker start), my container's vhosts.conf starts looking like:

# cat vhosts.conf 
DirectoryIndex index.php index.html

<VirtualHost *:80>
  ServerName local.dev
  DocumentRoot "/var/www/html/web/web/web/web"

  <Directory "/var/www/html/web/web/web/web">
    AllowOverride All
    Options -Indexes +FollowSymLinks
    Require all granted
  </Directory>
</VirtualHost>

Obviously need a little more intelligence with the overwriting of the DocumentRoot! Probably need to use the ending " as a marker or something.

This happens if you set the APACHE_DOCUMENT_ROOT to something like /var/www/html/anything-here.

Related to #18.

As the title says.

Oops... #12 seems to have broken the Travis CI tests. Will have to fix that up...

Sadly, PHP 7.0.33 no longer allows installation of Drupal from a Composer codebase using Drush... therefore I'd like to upgrade.

Debian/Raspbian Buster has PHP 7.2... so for now that might be the path of least resistance. Also need to switch from mysql-client to mariadb-client though.

See:

• https://hub.docker.com/r/resin/rpi-raspbian
• https://www.balena.io/docs/learn/welcome/introduction/

Apparently 'connected app' software is in the same rut as node.js... have to change names every few months if enough VC doesn't sustain on the first naming :P

Currently some files are owned by www-data, some by root, and this can cause issues depending on the container lifecycle, especially with things like files dir and settings.php permissions.

See, for reference, geerlingguy/raspberry-pi-dramble#104 (comment)

Example: https://travis-ci.org/geerlingguy/drupal-container/jobs/387257782#L536-L546

...
The command "ansible-playbook main.yml" exited with 0.

$ docker run -d --name=drupal -p 8080:80 geerlingguy/drupal:latest /usr/sbin/apache2ctl -D FOREGROUND
cec66b2fe4db64545d6210db049aa8607d270259c58aecb0f768405f15b4bcfc
The command "docker run -d --name=drupal -p 8080:80 geerlingguy/drupal:latest /usr/sbin/apache2ctl -D FOREGROUND" exited with 0.

$ curl http://localhost:8080/
curl: (52) Empty reply from server

The command "curl http://localhost:8080/" exited with 52.

When we run apt-get update in our Dockerfile using your geerlingguy/drupal:latest base image we are now getting the following error:

0.426 Get:1 http://deb.debian.org/debian buster InRelease [122 kB]                                                                                                 
0.511 Get:2 http://deb.debian.org/debian-security buster/updates InRelease [34.8 kB]                                                                               
0.512 Get:3 http://deb.debian.org/debian buster-updates InRelease [56.6 kB]                                                                                        
0.544 Get:4 https://packages.sury.org/php buster InRelease [7559 B]                                                                                                
1.756 Get:5 http://deb.debian.org/debian buster/main amd64 Packages [7909 kB]
3.015 Get:6 http://deb.debian.org/debian-security buster/updates/main amd64 Packages [592 kB]
4.210 Get:7 http://deb.debian.org/debian buster-updates/main amd64 Packages [8788 B]
5.334 Err:4 https://packages.sury.org/php buster InRelease
5.334   The following signatures were invalid: EXPKEYSIG B188E2B695BD4743 DEB.SURY.ORG Automatic Signing Key <[email protected]>
6.113 Reading package lists...
9.599 W: GPG error: https://packages.sury.org/php buster InRelease: The following signatures were invalid: EXPKEYSIG B188E2B695BD4743 DEB.SURY.ORG Automatic Signing Key <[email protected]>
9.599 E: The repository 'https://packages.sury.org/php buster InRelease' is not signed.

Add a DRUPAL_DOWNLOAD_IF_NOT_PRESENT environment variable, which defaults to true and can be overridden to skip the download if Drupal's not present.

This is helpful when, for example, someone is using this container and stashing Drupal inside /var/www/html/web... or any other location besides /var/www/html, really.

Currently the default is to download Drupal to the docroot using the tarball if nothing is there already, controlled via the DRUPAL_DOWNLOAD_IF_NOT_PRESENT environment variable.

Because of the issue Can't run PHPUnit tests since Drupal 8.8.0, I'd like to make it so it's easy to have the Drupal codebase cloned from the latest branch instead of automatically downloaded.

Not sure if I want to do this or not; people already have the official library Docker Drupal image on Docker Hub which has a preinstalled copy of Drupal baked in.

But if so, in entrypoint, I would have something like:

1. If no index.php in webroot (/var/www/web/index.php).
2. Create Drupal project in /var/www with composer create-project.

So after a brand new Drupal 8 install, the installer places the following into settings.php:

$databases['default']['default'] = array (
  'database' => 'drupal',
  'username' => 'drupal',
  'password' => 'drupal',
  'prefix' => '',
  'host' => 'mysql',
  'port' => '3306',
  'namespace' => 'Drupal\\Core\\Database\\Driver\\mysql',
  'driver' => 'mysql',
);
$settings['install_profile'] = 'standard';
$config_directories['sync'] = 'sites/default/files/config_8NvXCF2EiIMtDf7_v7H0PXFW_YnwVvlTcNARpqpmcKjFcPK1GjFWpszwF-A4MXa9GlK2Q6lDFw/sync';

Should we support more things being included at runtime? I'm trying to find a way to make all this stuff as automatable as possible for:

• First time setup with no Drupal available (e.g. for Pi Dramble use case: geerlingguy/raspberry-pi-dramble#104).
• Ongoing Drupal container build support: ideally also with the ability to set some things different if running locally, or in dev/stage vs prod, that sort of thing.

It seems like 99% of the Drupal containers out there are built for local dev only. Nobody really shares how they do Docker + Drupal in production. Maybe nobody really does? Or they all mount volumes for the codebase? (ICK!).

Follow-up to #8 — when I try building all three images and pushing them via GitHub Actions, I get:

***/drupal                                   latest-arm32v7    8afdc75c6ca4   1 second ago     440MB
***/drupal                                   latest            b82210279e7e   21 minutes ago   583MB
***/php-apache                               7.4               b5403a0d28e4   16 hours ago     484MB

But there's no latest-arm64 image in there. It says it runs it in the playbook output, but I'm wondering if a Docker context is messed up since the two that do appear are built by Ansible's docker_image module, whereas the arm64 build is using the command module, and calling docker build directly. Maybe the way BuildX is installed in GitHub Actions causes a failure here.

The Raspberry Pi foundation just released a beta of the Raspberry Pi OS 64-bit version, and it uses arm64 instead of armv7l, so I'd like to build a new tag version for arm64. See related: geerlingguy/drupal-pi#45

Currently there is only a latest tag pushed to docker hub. In light of #34 it would be nice if we had some old tags to pin releases to.

In a similar vein to #10 - without unzip / untar utilities, composer doesn't do a whole lot (especially without git as well.

I just ran a composer require and got:

# composer require drush/drush
Do not run Composer as root/super user! See https://getcomposer.org/root for details
Using version ^9.5 for drush/drush
./composer.json has been updated
Loading composer repositories with package information
Updating dependencies (including require-dev)
Package operations: 26 installs, 0 updates, 0 removals
    Failed to download webmozart/assert from dist: The zip extension and unzip command are both missing, skipping.
Your command-line PHP is using multiple ini files. Run `php --ini` to show them.
    Now trying to download from source
  - Installing webmozart/assert (1.4.0): Cloning 83e253c8e0

                                                                                                                       
  [RuntimeException]                                                                                                   
  Failed to clone https://github.com/webmozart/assert.git, git was not found, check that it is installed and in your   
  PATH env.                                                                                                            
                                                                                                                       
  sh: 1: git: not found 

So I should install an unzip-like utility in the ARM build so it works with Composer commands.

There are a couple more changes I'd like to make after completing #22 — with Drupal 8.8+, the recommended way to begin a new Drupal site codebase is with composer create-project, e.g.:

composer -n create-project drupal/recommended-project:^8.8@dev my-project

This is a bit different than other methods, because:

• It's not a git checkout
• It already has the composer install stuff done
• The 'recommended-project' layout places the web files in a 'web/' subdir (which is how drupal-project template did/does it)

And I'd also like to add a DRUPAL_RUN_COMPOSER_INSTALL env var as part of this, for those who wish to run it after a tarball or git clone.

Currently this container's entrypoint will download or install Drupal 8.x:

DRUPAL_CLONE_BRANCH=${DRUPAL_CLONE_BRANCH:-"8.8.x"}
DRUPAL_PROJECT_VERSION=${DRUPAL_PROJECT_VERSION:-"^8@dev"}

These defaults should be changed to the Drupal 9 equivalents.