MCLOUD-5752
In PR #113 we've added the concept of health checks and ES health checks as basic ones. The health checks should be added for other services as well.

AC

• Add health checks for next services:
  • PHP-FPM
  • MySQL
  • Redis
  • RabbitMQ

Hi! One of the things stopping my team from utilizing this project is that there isn't an obvious way for us to have the database be created from a dump file.

magento-cloud db:dump -p xxxxxxxx -e integration

It appears that it is creating the database from scratch.. Any help you can provide would really be appreciated. For now, we are stuck using a slower, but full featured Vagrant VM that we built in house.

Varnish is making it so xdebug is not working correctly.

Preconditions

1. Xdebug is on
2. Varnish is enabled

Steps to reproduce

1. Xdebug request do not connect, unless you restart varnish. Only first request (uncached) will work

Expected result

1. Every request with the cookie should work

To Do:

• Consider adding Selenium image with pre-configured MFTF to run MFTF tests against Cloud Docker environment locally

How to configure the docker containers to compile less using grunt?

Edit by @YPyltiai:
It appears that Grunt and similar tools do not work because Cloud Docker doesn't support dependencies parsing yet (https://devdocs.magento.com/cloud/project/project-conf-files_magento-app.html#dependencies).

To Do:

• Suggested solution: Add Yarn, Npm, Node, Grunt to PHP Container
• Alternatively: Add dependencies parsing functionality

Because of the comments added to php ini files there is errors logged.

Preconditions

1. On current develop branch

Steps to reproduce

1. Bring up containers
2. check logs using docker-compose logs fpm

Expected result

1. All offending lines would not show

[webuser@localhost ztgento]$ docker-compose logs fpm
/usr/lib/python2.7/site-packages/requests/__init__.py:91: RequestsDependencyWarning: urllib3 (1.25.6) or chardet (2.2.1) doesn't match a supported version!
  RequestsDependencyWarning)
Attaching to ztgento_fpm_1
fpm_1            | [16-Jan-2020 18:43:02] NOTICE: fpm is running, pid 1
fpm_1            | [16-Jan-2020 18:43:02] NOTICE: ready to handle connections

Actual result

[webuser@localhost ztgento]$ docker-compose logs fpm
Attaching to ztgento_fpm_1
fpm_1            | PHP:  syntax error, unexpected '!' in /usr/local/etc/php/conf.d/zz-magento.ini on line 2
fpm_1            | PHP:  syntax error, unexpected '!' in /usr/local/etc/php/conf.d/zz-magento.ini on line 2
fpm_1            | PHP:  syntax error, unexpected '!' in /usr/local/etc/php/conf.d/zz-magento.ini on line 2
fpm_1            | PHP:  syntax error, unexpected '!' in /usr/local/etc/php/conf.d/zz-magento.ini on line 2
fpm_1            | PHP:  syntax error, unexpected '!' in /usr/local/etc/php/conf.d/zz-magento.ini on line 2
fpm_1            | PHP:  syntax error, unexpected '!' in /usr/local/etc/php/conf.d/zz-magento.ini on line 2
fpm_1            | PHP:  syntax error, unexpected '!' in /usr/local/etc/php/conf.d/zz-magento.ini on line 2
fpm_1            | PHP:  syntax error, unexpected '!' in /usr/local/etc/php/conf.d/zz-magento.ini on line 2
fpm_1            | PHP:  syntax error, unexpected '!' in /usr/local/etc/php/conf.d/zz-magento.ini on line 2
fpm_1            | PHP:  syntax error, unexpected '!' in /usr/local/etc/php/conf.d/zz-magento.ini on line 2
fpm_1            | PHP:  syntax error, unexpected '!' in /usr/local/etc/php/conf.d/zz-magento.ini on line 2
fpm_1            | PHP:  syntax error, unexpected '!' in /usr/local/etc/php/conf.d/zz-magento.ini on line 2
fpm_1            | PHP:  syntax error, unexpected '!' in /usr/local/etc/php/conf.d/zz-magento.ini on line 2
fpm_1            | PHP:  syntax error, unexpected '!' in /usr/local/etc/php/conf.d/zz-magento.ini on line 2
fpm_1            | PHP:  syntax error, unexpected '!' in /usr/local/etc/php/conf.d/zz-magento.ini on line 2
fpm_1            | PHP:  syntax error, unexpected '!' in /usr/local/etc/php/conf.d/zz-magento.ini on line 2
fpm_1            | PHP:  syntax error, unexpected '!' in /usr/local/etc/php/conf.d/zz-magento.ini on line 2
fpm_1            | PHP:  syntax error, unexpected '!' in /usr/local/etc/php/conf.d/zz-magento.ini on line 2
fpm_1            | PHP:  syntax error, unexpected '!' in /usr/local/etc/php/conf.d/zz-magento.ini on line 2
fpm_1            | PHP:  syntax error, unexpected '!' in /usr/local/etc/php/conf.d/zz-magento.ini on line 2
fpm_1            | PHP:  syntax error, unexpected '!' in /usr/local/etc/php/conf.d/zz-magento.ini on line 2
fpm_1            | [16-Jan-2020 18:33:44] NOTICE: fpm is running, pid 1
fpm_1            | [16-Jan-2020 18:33:44] NOTICE: ready to handle connections

When first starting docker-sync, the period of inactivity experienced by syncing any large files (>1 GB) creates the impression that something may be wrong. Large files like DB dumps and archives are unnecessary to sync. Add the following file types to the default ignore section of docker-sync.yaml:

• *.sql
• *.gz
• *.zip
• *.bz2

Preconditions

First run of docker-sync. A DB dump file downloaded using magento-cloud db:dump exists in the project root.

Steps to reproduce

docker-sync start

Expected result

DB dumps and other large files should be ignored by the sync.

Actual result

The wait is long while syncing the DB dump.

Preconditions

1. Cloud project cloned
2. Cloud Docker compose file generated

Steps to reproduce

1. Add custom changes to docker-compose.yml
2. Run ./vendor/bin/ece-docker build:compose

Expected result

1. Custom changes preserved

Actual result

1. File content fully replaced

https://jira.corp.magento.com/browse/MCLOUD-5857:
Blackfire.io is a crucial development tool. This is part of the cloud integration and can be added to the Magento Cloud Docker.

1. Include https://hub.docker.com/r/blackfire/blackfire container if the extension is enabled
2. Build with Blackfire Extension in php
3. Add support for the configuration injecting into containers as needed.

Work has already been started, just wanted an issue so we can talk about it.

During last grooming, we agreed to have native mode the default one so no additional tools needed. Later SI can choose the tool which they need.

Preconditions

1. Magento is cloned locally

Steps to reproduce

1. Generate docker-compose in Developer mode

Expected result

1. The default mode us --native

Actual result

1. The default mode is docker-sync

Internal ID: MAGECLOUD-3939

We don't currently support warm-up during the post-deploy hook in Docker implementation. This is past of ECE-Tools post-deploy process and has to be fixed.

To Do:

• Fix warm-up process to properly warm-up pages without errors in Cloud Docker implementation

I'm unable to start anything with docker-compose as there is no docker-compose.yml file.

Docker containers do not have health checks, so you can run commands before the services are ready. Adding a healthcheck allows for automation around the standup of the application, because currently there is a wait period while db and elasticsearch and phpfpm are ready.

https://docs.docker.com/engine/reference/builder/#healthcheck
These can be used in docker-compose: https://docs.docker.com/compose/compose-file/#healthcheck

Having this on services like elasticsearch, db and fpm would be great.

Here is a guide on the process for php-fpm: https://github.com/renatomefi/php-fpm-healthcheck

Even just having this on the fpm container would be a huge improvement, because this is the last container to come up and be ready.

"magento/magento-cloud-docker": "1.0.x-dev as 1.0.99",

in equired section of composer.json

get error:

Your requirements could not be resolved to an installable set of packages.

Problem 1
- The requested package magento/magento-cloud-docker could not be found in any version, there may be a typo in the package name.

Potential causes:

• A typo in the package name
• The package is not available in a stable-enough version according to your minimum-stability setting
  see https://getcomposer.org/doc/04-schema.md#minimum-stability for more details.
• It's a private package and you forgot to add a custom repository to find it

Read https://getcomposer.org/doc/articles/troubleshooting.md for further common problems.

For those that don't know the difference between stopping and downing a container, DB data should be stored in a volume. This prevents accidental data loss.

Preconditions

Development is in progress on a working docker environment with a DB previously imported.

Steps to reproduce

docker-compose down

Expected result

docker-compose up would restore the development environment with DB data persisted from last dev session.

Actual result

A new "blank" DB container is created. DB changes from previous dev sessions lost.

Summary

Add the latest version of node, npm and grunt-cli

Expected result

1. As a frontend developer, I should have to have the ability to use grunt-cli inside a PHP container (like the fpm)
2. I need node/npm/grunt-cli inside a php container because some tasks use PHP and database connection

Actual result

1. We don't have the ability to use node, npm or grunt-cli

Suggestion

Add a new RUN command to Dockerfile, something like this:

RUN curl -sL https://deb.nodesource.com/setup_12.x | bash - \
    && apt-get install -y --no-install-recommends nodejs \
    && npm install -g grunt-cli

Internal ID: MAGECLOUD-4107

We provide default php.ini file which is used on Cloud and should be read on Docker as well.

To Do:

• Read php.ini from the root and apply settings on Docker
• php.ini can be customized and should be read on Docker as well

Hello, Community

I would like to describe one problem came during developing #31

In nutshell, we want to get closer to the real Cloud environment and introduce web:web user instead of root.

I will skip technical details, but essentially there will be 2 sets of PHP images:
php-{cli|fpm}-{version} and php-{cli|fpm}-{version}-dev, where -dev images will represent developer environment.

The problem is hidden in Docker Hub versioning policy and ECE-Tools publication process.

Imagine, we'll deliver new -dev images to Hub and this will break current Docker setups because the latest version of ECE-Tools won't know anything about -dev images. And the new version of non-dev images won't run in Developer mode anymore.

To be able to generate docker-compose.yml file properly according to images, we moved all Docker functionality to https://github.com/magento/magento-cloud-docker

This will essentially be released as a new Composer package magento/magento-cloud-docker:1.0.0 let's call it MCD

In result, we will get into one of 2 situations:

• A: Release MCD without new images. This will not break current setups, but MCD package won't be useful.
• B: Release images first, which will break Dev setups, and only fix will be to manually add -dev to php images or require MCD package (which is not obvious) or update to a newer version of ECE-Tools with MCD dependency included.
• C: Stop automatic Docker Hub images publication from the master. Switch to MCD <=> Hub versioning policy. Where images will be versioned like magento/magento-cloud-docker-php:7.1-1.0.0

Preconditions

1. Have run mutagen.sh
2. Subsequent runs create multiple mutagen sessions

Steps to reproduce

1. Set up docker with mutagen
2. Run mutagen.sh
3. Rerun mutagen.sh

Expected result

1. Session would be recreated

Actual result

1. More than one session is created, old ones are stale

[webuser@localhost project-m2]$ ./mutagen.sh
Created session c75abb45-74ad-4cf0-ab3b-d3c51bf65a7a
[webuser@localhost project-m2]$ ./mutagen.sh
Created session bf2a3f2b-815b-43d3-9b9c-fafd806a6bfb
[webuser@localhost project-m2]$ mutagen sync list

Identifier: c75abb45-74ad-4cf0-ab3b-d3c51bf65a7a
Labels: None
Alpha:
URL: /home/webuser/docker/project-m2
Connection state: Connected
Beta:
URL: docker://e87016098b2bedfc25da6fd35ad9c5e7dd2eaacc104711765a2399866c6a7bb3/app
DOCKER_HOST=
DOCKER_TLS_VERIFY=
DOCKER_CERT_PATH=
Connection state: Connected
Status: Scanning files

Identifier: bf2a3f2b-815b-43d3-9b9c-fafd806a6bfb
Labels: None
Alpha:
URL: /home/webuser/docker/project-m2
Connection state: Connected
Beta:
URL: docker://e87016098b2bedfc25da6fd35ad9c5e7dd2eaacc104711765a2399866c6a7bb3/app
DOCKER_HOST=
DOCKER_TLS_VERIFY=
DOCKER_CERT_PATH=
Connection state: Connected
Status: Scanning files

The package procps is missing, so you will not have "ps" available as command. I don't know if anybody uses this for integration tests.

After installation of the latest docker images with with Magento 2.2.2 I am receiving the following error:

Fatal error: Uncaught Magento\Framework\Exception\FileSystemException: Cannot read contents from file "/var/www/magento/app/etc/di.xml" Warning!file_get_contents(/var/www/magento/app/etc/di.xml): failed to open stream: No such file or directory in /var/www/magento/vendor/magento/framework/Filesystem/Driver/File.php:149 Stack trace: #0 /var/www/magento/vendor/magento/framework/Filesystem/File/Read.php(100): Magento\Framework\Filesystem\Driver\File->fileGetContents('/var/www/magent...', NULL, NULL) #1 /var/www/magento/vendor/magento/framework/Config/FileIterator.php(71): Magento\Framework\Filesystem\File\Read->readAll() #2 /var/www/magento/vendor/magento/framework/Config/Reader/Filesystem.php(146): Magento\Framework\Config\FileIterator->current() #3 /var/www/magento/vendor/magento/framework/Config/Reader/Filesystem.php(130): Magento\Framework\Config\Reader\Filesystem->_readFiles(Object(Magento\Framework\Config\FileIterator)) #4 /var/www/magento/vendor/magento/framework/App/ObjectManagerFactory.php(275): Magento\Framework\Co in /var/www/magento/vendor/magento/framework/App/ObjectManagerFactory.php on line 277

This was verified on CentOS and WSL. Please let me know whether you need any additional details.

Steps to reproduce:

• Install ECE-Tools 2002.0.21
• Run ./vendor/bin/ece-tools docker:build

Expected Behavior:

• Config is created successfully

Actual Behavior:

• Error PHP extension bcmath is not available for PHP version 7.3. is displayed

Preconditions

Current Documentation on Docker: https://devdocs.magento.com/guides/v2.3/cloud/docker/docker-development.html
There is no documentation of the containers/services.

Current List of Services:

• build
• deploy
• cron
• db
• elasticsearch
• redis
• rabbitmq
• tls
• varnish
• web
• fpm

Steps to reproduce

Docker documentation is missing detailed service definitions. There is no request flow diagram and it is hard to understand the internal workings of each of the containers without documentation. Most containers have some amount of configuration that can be done using
configuration files.

Expected result

Detailed service definitions, for each of the containers that include any configuration that can be done. Pages that do exist like configuring Xdebug, or connecting to the database should probably be moved under the proper service container headers as well.

There are all sorts of useful things like changing out what modules are being loaded, changing configuration of the services and so on that can be done using the existing containers. All of this should have a more structured home, and should be easy to add to the documentation.

In addition to the service containers, there is also the request flow to help people understand how to debug. ie. tls->varnish->web->php-fpm. Additional information about debugging, or customizing the request flow will naturally fit here.

Internal ID: MAGECLOUD-3534

Steps to reproduce:

• Deploy Magento using Cloud Docker
• Open storefront using HTTPS

Expected behavior:

• Storefront opens with valid certificate

Actual behavior:

• Storefront opens with warning about not recognized self-signed certificate

Docker on Linux does not need 3rd party file syncing utilities as binding a host directory to a container does not suffer from the same performance issues as Windows or macOS

Preconditions

1. build docker environment on a Linux to generate docker-compose.yml file.

Steps to reproduce

1. Start and deploy the Docker do not use docker-sync or mutagen
2. Make change to your code, you will not see the change on the site.

Expected result

1. docker-compose that is generated with the magento-sync volume as a bind type.
2. Changes on host will be immediately reflected in fpm container.

Actual result

1. Cannot use the docker cloud on Linux without using mutagen or docker-sync (slower and unnecessary) or modifying the docker-compose.yml manually.

Internal ID: MAGECLOUD-3243

As a Magento developer, I want local dev solution to be working OOTB without me configuring additional technical stack parts, so it's easy and fast to set environment up.

To Do:

• Consider adding some Docker-native way to build the stack (PHP + Composer to avoid setting up anything natively besides Docker)
• Capability to isolate dev dependencies natively for production mode

Problem

Docker generation functionality is growing fast and became complicated.

Proposal

To maintain good code quality and have the possibility of independent releases - we should separate it to a new repository.

Repository

The code should be moved to images source code repo - https://github.com/magento/magento-cloud-docker

Backward compatibility

Backward compatibility must be preserved

Does Magento support this project officially? If we have enterprise level support - would magento support answer questions and provide guidance to using this cloud version of docker

To improve the developer's experience, we should add an option --from-sources which will point docker-compose to image sources instead of published images. This will give a possibility to properly and easily test changes into images locally.

Preconditions

1. Cloud Docker is installed
2. Cloud project is cloned

Expected result

1. Cannot build from sources

Actual result

1. Option with building from sources added

build container should not access to services like db, redis, etc to emulate Cloud.

Preconditions

1. Project is cloned
2. Containers are up

Steps to reproduce

1. SSH into build container docker-compose run build bash
2. Curl db container curl db:3306

Expected result

1. Connection refused, as DB container not available

Actual result

1. Container is avaible

Environments on cloud support the ionCube Loader but developers do not have it locally.

Preconditions

1. Add ioncube to the list of extensions in .magento.app.yaml file.

Steps to reproduce

1. Start or deploy your environment

Expected result

1. Should see that ioncube is loaded when you run php -v on the fpm container.

Actual result

1. php -v does not show that ionCube is installed.
2. Have to manually install it or else encrypted php code will not execute.

Cloud Docker includes Mutagen script which creates a session to share files between the local machine and Docker containers. This script creates only one session for the whole scope. vendor directory is huge and potentially can cause Mutagen to stuck. To be able to restart it we should have a separate session for this directory.

Preconditions

1. Cloud project is cloned
2. Cloud Docker is set-up in develop mode with mutagen

Steps to reproduce

1. Run ./mutagen.sh

Expected result

1. Separate sessions are created

Actual result

1. Only one session is created for the whole scope

The docker:build command is problematic, in that it sets up dependencies for the environment in which you are running it for. With Mac or Windows you have very specific requirements for making the containers work properly. Currently when you run docker:build it generates all these requirements and puts them in the docker-compose.yaml file.

Ideally this process would work slightly differently. Instead you would generate docker-compose.yaml with as minimal amount is needed to run it on all systems(linux), and any requirements that are specific would go into environment configs:
docker-compose-mac.yaml
docker-compose-windows.yaml

This still leaves docker-compose.override.yaml alone, which you should so that developers can make any final changes for their specific environment easily.

This would allow a different workflow, where the docker-compose files can be checked into the repository and version controlled. When the docker:build command is run it can update each of these environment override files.

Another adjustment that would be need to happen is to allow for people to boot up the proper overrides when they do the docker-compose up -d, this can be in the documentation and also in the ./bin/docker start command.

With this architecture you can support ALL three linux, mac and PC with the same set of docker-compose files, and not have to switch back and forth when you are in a different environment. This is very common because these same docker containers should be used by jenkins or circleci etc, to run the smoke tests, run unit tests and a variety of other tasks.

The goal here is to have the same containers through out the entire development stack, and also to be able to version the docker-compose files so that you can support multiple environments at the same time.

Background:

• There is a need for users to apply custom Nginx configurations for their Cloud Docker environments
• Currently Cloud Docker uses hard-coded configurations

To Do:

• Add possibility to mount custom nginx.conf to Cloud Docker environments

Latest versions of ECE-Tools build magento volumes with an environment variable:

magento:
    driver_opts:
      type: none
      device: '${PWD}'
      o: bind

${PWD} is not available on Windows machines and must be replaced by the full path to current directory.

To Do:

• Detect OS during docker-compose file generation and put the path to the current directory for Windows machines

For multi-threaded testing we need possibility to run build/deploy phases once and re-use generated slug in multiple other environments.

• Add option to mount all directories to local FS (use native option for Prod mode)

To expand Cloud Docker presence and align wit platform-agnostic vision of ECE-Tools we should provide a non-Magento-Cloud way to install Docker so developers with own infrastructure could use it.

https://jira.corp.magento.com/browse/MCLOUD-5859:
When we're trying to use multiple projects using the docker environment we receive an error because the volume name is fixed in some files.

Preconditions

1. I've tried with Linux OS (More specifically Fedora 30)

Steps to reproduce

1. Mount a project using docker environment (Developer mode)
2. After that, try to create another one using the same architecture

Expected result

1. Both projects should work with no error

Actual result

1. We face an error because they are sharing the same volume so Magento is already installed when we try to install again
2. It brokes exactly when we try to execute docker-compose run deploy cloud-deploy

Solutions

I had to change manually some files with a different sync name, like this:

PROJECT_NAME="project2"
SYNC_NAME="${PROJECT_NAME}-sync"
sed -i -E "s/(.*)magento-sync(.*)/\1${SYNC_NAME}\2/" ./docker-compose.yml ./docker-sync.yml ./vendor/magento/ece-tools/src/Docker/Compose/DeveloperCompose.php

I think that a .env file could be a good solution

Preconditions

1. Docker version 18.09.2, build 6247962
2. OSX: 10.14.5 (18F132)

Steps to reproduce

1. docker pull magento/magento-cloud-docker-php:7.2-cli
2. docker run magento/magento-cloud-docker-php:7.2-cli php -m

Expected result

1. [Screenshots, logs or description]
   Starting enhanced syslogd: rsyslogd.
   [PHP Modules]
   bcmath
   Core
   ctype
   curl
   date
   dom
   fileinfo
   filter
   ftp
   gd
   hash
   iconv
   intl
   json
   libxml
   mbstring
   mysqlnd
   openssl
   pcre
   PDO
   pdo_mysql
   pdo_sqlite
   Phar
   posix
   readline
   Reflection
   session
   SimpleXML
   soap
   sockets
   sodium
   SPL
   sqlite3
   standard
   tokenizer
   xml
   xmlreader
   xmlwriter
   xsl
   Zend OPcache
   zip
   zlib

[Zend Modules]
Zend OPcache

Actual result

1. [Screenshots, logs or description]
   [PHP Modules]
   Core
   ctype
   curl
   date
   dom
   fileinfo
   filter
   ftp
   hash
   iconv
   json
   libxml
   mbstring
   mysqlnd
   openssl
   pcre
   PDO
   pdo_sqlite
   Phar
   posix
   readline
   Reflection
   session
   SimpleXML
   SPL
   sqlite3
   standard
   tokenizer
   xml
   xmlreader
   xmlwriter
   zlib

[Zend Modules]

Introduction

To provide the best quality for Magento Cloud, we should ensure that all delivered features are properly tested from a functional perspective. With the rapidly growing Magento Cloud ecosystem, it's being even more difficult to fulfill this requirement.

Terms

• ECE-Tools - Main Cloud deployment package (https://github.com/magento/ece-tools)
• Cloud Components - Set of additional Magento modules (https://github.com/magento/magento-cloud-components)
• Cloud Patches - Set of security and functional patches (https://github.com/magento/magento-cloud-patches)

Problem

ECE-Tools was decoupled into 4 different packages:

• ECE-Tools
• Cloud Docker
• Cloud Tools
• Cloud Patches

To be able to verify the quality, we should run a set of functional tests to check the integration between Cloud Tools and the Magento version. This part is already done as ECE-Tools Functional Tests. But these tests must be applied also to all of the Magento Cloud ecosystem for each code change being delivered.

Design

We should decouple the Functional Testing framework into Cloud Docker with the possibility to run specific tests for each of Cloud packages. Next diagram provides a visual representation of relations between different packages where Cloud Docker is required for all of them to provide testing infrastructure.

Responsibilities

Cloud Docker will have next responsibilities:

• Provide an extension point to set the set of Functional Tests
• Provide a mechanism to generate a configurable test environment
• Provide tests for its own testing

This is an easy fix, will include a PR in a bit.

Preconditions

1. Current docker-compose doesn't expose 3306

Steps to reproduce

1. Bring up docker
2. Notice the port is not exposed using docker-compose ps

Expected result

1. It should look like this

magento-m2_db_1 docker-entrypoint.sh mysqld Up 0.0.0.0:3306->3306/tcp

Actual result

1. Not exposed

magento-m2_db_1 docker-entrypoint.sh mysqld Up

Any help here?
While testing out the process for ece tools v2002.0.13 per the documentation, everything seems to run fine until the last step. Running docker-compose run deploy cloud-deploy results in the following error:

$ docker-compose run deploy cloud-deploy
Starting mccdocker_appdata_1 ... done
Starting mccdocker_dbdata_1 ... done
Starting mccdocker_redis_1 ... done
Starting mccdocker_db_1 ... done
Deploying Magento Cloud...
[2018-08-15 15:43:12] NOTICE: Starting deploy. (magento/ece-tools version: 2002.0.13, magento/magento2-base version: 2.2.5)
[2018-08-15 15:43:12] INFO: Starting pre-deploy.
[2018-08-15 15:43:12] INFO: Skip copying directory ./var/view_preprocessed.
[2018-08-15 15:43:12] INFO: Clearing ./var/view_preprocessed
[2018-08-15 15:43:12] INFO: Clearing redis cache
[2018-08-15 15:43:12] INFO: redis-cli -h redis -p 6379 -n 1 flushdb
[2018-08-15 15:43:12] CRITICAL:
sh: 1: redis-cli: not found
[2018-08-15 15:43:12] INFO: Set flag: var/.deploy_is_failed
[2018-08-15 15:43:12] CRITICAL: Command redis-cli -h redis -p 6379 -n 1 flushdb returned code 127

[RuntimeException]
Command redis-cli -h redis -p 6379 -n 1 flushdb returned code 127

To Do:

• Add possibility to specify custom base URL for Magento Cloud Docker installation

I'm using this docker to add another website to my local, however i keep getting redirected back to http://magento2.docker/

My magento project is currently using Magento 2.2.5

Steps to reproduce

1. Start the magento cloud docker, set to developer deploy mode following this tutorial: https://devdocs.magento.com/guides/v2.3/cloud/docker/docker-config.html
2. Set up a new website, store, store view and use this tutorial to set up a new website: https://devdocs.magento.com/guides/v2.3/cloud/project/project-multi-sites.html
3. Assuming we plan to have http://second.magento2.docker/ for the new website that i'm adding, i also added this to hosts file:

127.0.0.1 magento2.docker
127.0.0.1 second.magento2.docker

4. Updated base url for the new website, re-deployed, cleared caches

Expected result

1. Going to http://second.magento2.docker/ should show the second website that was set up

Actual result

1. Going to http://second.magento2.docker/ keeps redirecting back to http://magento2.docker, showing the old website

According to recent documentation published in the README, and to reference related issue #10, I tried this import procedure but encountered a failure:

Starting XXXX_appdata_1 ... done
Starting XXXX_dbdata_1  ... done
Starting XXXX_redis_1   ... done
Starting XXXX_db_1      ... done
[ ok ] Starting enhanced syslogd: rsyslogd.
Deploying Magento Cloud...
[2018-09-26 00:35:19] NOTICE: Starting deploy. (magento/ece-tools version: 2002.0.13, magento/magento2-base version: 2.2.6)  
[2018-09-26 00:35:19] INFO: Starting pre-deploy.  
[2018-09-26 00:35:19] INFO: Skip copying directory ./var/view_preprocessed.  
[2018-09-26 00:35:19] INFO: Clearing ./var/view_preprocessed  
[2018-09-26 00:35:19] INFO: Clearing redis cache  
[2018-09-26 00:35:19] INFO: redis-cli -h redis -p 6379 -n 1 flushdb  
[2018-09-26 00:35:19] INFO: Recoverable directories were copied back.  
[2018-09-26 00:35:19] INFO: Disable cron  
[2018-09-26 00:35:19] INFO: Trying to kill running cron jobs  
[2018-09-26 00:35:19] INFO: exec pgrep -f 'bin/magento cron:run'  
[2018-09-26 00:35:19] INFO: Running Magento cron processes were not found.  
[2018-09-26 00:35:19] INFO: Validating configuration  
[2018-09-26 00:35:19] INFO: Checking if db exists and has tables  
[2018-09-26 00:35:19] INFO: Set flag: var/.deploy_is_failed  
[2018-09-26 00:35:19] CRITICAL: SQLSTATE[HY000] [2002] Connection refused  

                                             
  [PDOException]                             
  SQLSTATE[HY000] [2002] Connection refused  
                                             

deploy

I see that you pulled this tip from the corresponding Docker image feature:

https://github.com/docker-library/mariadb/blob/master/10.0/docker-entrypoint.sh#L169

Now I see that my SQL file has been mounted if I run:

docker-compose run db bash -c "ls -larth /docker-entrypoint-initdb.d/"

But something about this fails to run when the container is started. Do you have any thoughts on what could be causing this issue? In the meantime I'm researching the behavior of this container and its companion initialization script /docker-entrypoint.sh.

To be able to effectively process and community regarding the contributions, we should provide documentation CONTRIBUTING.md similar to https://github.com/magento/adobe-stock-integration/blob/develop/.github/CONTRIBUTING.md

Internal ID: MAGECLOUD-3248

As a Magento developer, I want local dev solution to provide more granular controls over mounts and file system, so I can easily configure mounts without side effects on performance.

To Do:

• Split /var/www/magento/pub volume to /var/www/magento/pub/static and /var/www/magento/pub/media
• Add more control over mounts (ie - possibility to modify the list of volumes)

      - /var/www/magento/vendor
      - /var/www/magento/generated
      - /var/www/magento/pub
      - /var/www/magento/var

• Consider adding possibility to configure mounts through .magento.app.yaml

Preconditions

1. Magento 2.3.1

Steps to reproduce

1. Perform any action on HTTPS that takes longer than 15 seconds, such as deleting a customer.

Note: Only occurs on HTTPS pages that have not been cached by Varnish.

Expected result

1. The website should perform the expected action.

Actual result

1. The website displays the following error message:

An internal server error occurred. Please try again later.

2. And docker-compose logs tls displays the following error:

tls_1            | (7f07bb9ca700) e500 for 172.18.0.1 response error read from 172.18.0.9:80/POST /admin/scommerce_gdpr/newsletter/deletePersonalData/key/8529da357b06edf6f740fa28ad64c857b1d95912ee97c27bbcb7962b6b5674cc/ HTTP/1.1: Connection timed out (14.967 secs)

Fix

Add the TimeOut 300 parameter to the pound.cfg file.

Workaround

Add the HTTPS_UPSTREAM_SERVER_PORT to the docker-compose.yml file:

  tls:
    image: 'magento/magento-cloud-docker-tls:latest'
    ports:
      - '443:443'
    external_links:
      - 'varnish:varnish'
    depends_on:
      - varnish
    environment:
      HTTPS_UPSTREAM_SERVER_PORT: "80\n\t\t\tTimeOut 300"

Internal ID: MAGECLOUD-3598

Background:

• Currently on Cloud Docker we set up Varnish by default but do not configure it properly
• Since traffic is still going through it, we get a number of unexpected issues

To Do:

• Set up Varnish as default cache instead of MySQL for Cloud Docker

xDebug is a critical feature of a development environment. But, it use is often intended only for the local development environment. Currently to enable xDebug in the Cloud Docker, a Cloud configuration file needs to be modified. (.magento.app.yaml) In the most common use-case for utilizing xDebux developers will want it enabled locally while developing or troubleshooting an issue, but do not intend for it to be enabled in the Cloud environment. This causes them to continually have to configure and "unconfigure" xDebug before and after committing code.

Preconditions

A development task that requires xDebug use locally.
No intention to have xDebug enabled in the Cloud environment.

Steps to reproduce

Configure local Cloud docker to use xDebug.
Use xDebug to solve an issue.
"Unconfigure" xDebug.
Commit code, create pull request.

Expected result

Developer should not have to configure and "unconfigure" xDebug per issue.

Actual result

Developer has to configure and "unconfigure" xDebug per issue. (In a large organization, developers will inevitably forget to do this occasionally, causing xDebug to be inadvertently enabled in the Cloud environment.)