drupalstand / drupal-dev-docker Goto Github PK

returns Error: No such object: govcon-2018-drupal-{db,php,web} the expansion doesn't work.

Make version
arch 4.2.1
ubuntu 4.1

Bash version
arch 4.4.23
ubuntu 4.4.19

Running make in a zsh shell didn't help

If cloning repo to system with a name that starts with an uppercase letter, on init it will fail.

Building db
ERROR: invalid reference format: repository name must be lowercase

The idea is a make command which would run a few performance tests to give some idea of the current performance of the application.

Could use something like ab apache bench or similar to load testing a few default drupal pages.
Could use time to test the speed at which drush status shows results

We want to test how fast our development environment is working

First, amazing work on this project. I have been looking hard for something that demonstrated an end-to-end development process for Drupal and Docker.

My ultimate deployment will be on Kubernetes (driven with Helm). I am left with a couple production deployment questions.

1. When pushing the new production images, what tasks should be performed? Should a Kubernetes job perform the equivalent of "make update"? Surround this with entering maintenance mode?
2. What about persisting sites/default/files? Any recommendations for this? In a single node configuration, is a PersistentVolume adequate?

Thanks again for the fantastic project!

dbupdate needs to be added to update and safe-update targets

opcache key/value is suppose to be much faster than redis or other caching methods. Might be useful for local dev?

I believe we can fix all permission issues once and for all by passing the host UID into the docker build process and creating/manipulating users inside each container to match the host.

php unit must be update to ^6.5 to be compatible with php 7.

mobomo/composer now has available the 2.0 tag. Please test this as latest will eventually become 2.0

Alt title: How to force Drupal 8/9 to output HTTPS URLs when using an nginx reverse proxy

Insert into settings.php

$settings['reverse_proxy'] = TRUE;
$settings['reverse_proxy_addresses'] = array($_SERVER['REMOTE_ADDR']);

And forward appropriate headers with nginx config

proxy_set_header X-Forwarded-Proto https;
proxy_set_header X-Forwarded-Port 443;

Or with apache in mod_headers.c section

RequestHeader set X-Forwarded-Proto https
RequestHeader set X-Forwarded-Port 443

Thanks @jeffbeagley

Talking with Fred. Talked about how the native driver might have better caching and overall performance.

We know the host system depend on the following tools on 2.0

• docker
• docker-compose
• gnumake
• python
• bash
• git
• ssh? ( if cloning via git:// ?)

The images created secondarily from the original source (FROM scratch as php-dev COPY --from=php-base . /) do not inherit the environment variables from the base. The file structure is the same, but other Docker set items such as ENV and ENTRYPOINT are not inherited.

ENV specifically causes an issue with compiling xdebug (or other php extensions) because the script for it expects PHP_INI_DIR=/usr/local/etc/php to exist.

Move usage of GNUMake, bash, ect into a container to eliminate further OS issues.

Used on AORG atm

Looks to be a great win especially if we can package the file cache inside docker.

https://medium.com/@dylanwenzlau/500x-faster-caching-than-redis-memcache-apc-in-php-hhvm-dcd26e8447ad

; configuration for php opcache module
; priority=10
zend_extension=opcache.so
opcache.file_cache=/var/php/opcache
opcache.file_cache_only=1 # Useful for CLI
opcache.file_cache_consistency_checks=1
opcache.memory_consumption=128 # MB
opcache.max_accelerated_files=10000
opcache.max_wasted_percentage=10

The handcrafted maria db contaienr isnt reading the map.cnf file most likely because the default alpine install doesn't know to look for extra cnf files like the official docker images do. We need to either switch to an official image or rework the configuration for the db container.

tldr, drupal breaks hard because max packet size is 1mb by default.

Hey there. I was wondering if anyone has tried using this on a Mac with any success. I've been trying for the past week but had to give up due to how slow/unresponsive it was. I've even tried giving Docker Desktop all my CPU and Memory to no avail. A simple drush command can take over 5 minutes :(

Any help or advice would be greatly appreciated :)

Composer update can take forever. Satis should allow a much faster update time.

When running the make command, this is the output I get.
#blame/u/jackinloadup

Please specify a target. See README for information about targets.
                                                                  
column: invalid option -- 'N'                                     
usage: column [-txne] [-c columns] [-s sep] [file ...]            
Makefile:19: recipe for target 'help' failed                      
make: *** [help] Error 1                                          

I think something like make help would be useful.

It envision it would access a markdown file for the different commands. These markdown files would have name, description, in depth article on why you would want to use it, example commands.

Please add in tags. say we start at 1.0 then each PR or w/e you want we do 1.1. following Semver.

I think we should do this to allow some visibility when projects are forked from here and allows us to properly display a drastic change with 2.0.

WSL, Debian 10.

$ bin/drush-debug pm-enable parler
sh: XDEBUG_CONFIG=remote_host=172.17.0.1: not found