ellioseven / de Goto Github PK

4. (Optionally) Add Host

Should be

3. (Optionally) Add Host

Investigate implementing an ngrok service that can open tunnels to services. This will be particularly useful for tunnelling into the Apache service

Create a wrapper script that will destroy the containers in the environment. Similar to docker-up.sh

Apache and PHP service rely on a docroot directory. It would be great for this to customisable so that the directory structure is not enforced.

When connecting to remotes via ssh, the system cannot write to /home/app/.ssh/known_hosts as it's read only (upon mounting the private key). An empty known hosts file can be mounted to prevent this issue.

services:
  php:
    image: "ellioseven/de-drupal:5.6"
    volumes:
      - ./etc/php/ssh/known_hosts:/home/app/.ssh/known_hosts

When cloning .de via git protocol, it looks like ssh auth is required. We should clone via https instead?

# Requires auth?
git submodule add [email protected]:ellioseven/de.git .de

# Doesn't require auth?
git submodule add https://github.com/ellioseven/de.git .de

I propose that projects are structured like so:

.
├── .de
├── docker-compose.override.yml
├── docker-compose.yml
├── services
│   └── php
│       └── etc
│           └── php.ini
└── src
    └── docroot
        └── index.php

Documentation will need to be created to outline the preferred project structure.

https://docs.docker.com/compose/compose-file/compose-file-v2/#extends

This can simply extend the official MySQL Docker images and supply the default user/password within the Dockerfile template environment variables.

This way we can eliminate the following from docker-compose.yml:

MYSQL_ROOT_PASSWORD: root

Would be great if we could somehow download and select drush aliases from Acquia which we could import into the environment.

In services/php/docker-compose.yml:

services:
  php:
    volumes:
      - ./lib/composer:/home/app/.composer
    ...

This unfortunately overlays the composer global packages within the PHP image. We loose packages such as presstisimo.

Looking at the mysql image, they somehow allow the volume to copy the data volume from the container into the host. How can we do that?

I am getting reoccuring file permission issues with vendor directories such as Composer's vendor directory and NPM's .npm-packages directory as well as empty docroots.

Please add .composer, .npm-packages and src/docroot to the stack, so correct permissions are applied before mounting.

.
├── .composer
│   └── .gitkeep
├── .npm-packages
│   └── .gitkeep
├── src
│   └── docroot
│       └── .gitkeep
...

Currently de is designed to be cloned and then pushed to a projects repository. If there are changes to de, it's difficult to import that into the existing project.

I propose that projects are structured like so:

.
├── .de
├── docker-compose.override.yml
├── docker-compose.yml
├── services
│   └── php
│       └── etc
│           └── php.ini
└── src
    └── docroot
        └── index.php

Projects can be initiated like so:

# Init
mkdir <project> && cd <project>
git init

# Create de
git submodule add <git-location> .de
cp .de/.gitignore ./
cp .de/docker-compose.example.yml docker-compose.yml
cp .de/docker-compose.override.example.yml docker-compose.override.yml
git add --all && git commit -m "Add environment"

# Create build
git submodule add <git-location> src
git add --all && git commit -m "Add build"

The project will be based around 3 repositorys, the build, the environment and de. The project will also need to follow a submodule workflow.

Note: /src will likely have to be removed from .gitignore to allow submodules

Documentation or workflow will need to be changed to interact with the Makfile. Perhaps we can replace this with a simple cli script, eg:

./de/bin/cli up
./de/bin/cli down
./de/bin/cli host --host=apache

Alternatively, if the submodule workflow is too complicated, the de and build repository can be cloned and ignored by the environment repository.

During develop, it's useful to keep a tmp in the project root. Let's add /tmp into .gitignore so we can create that directory ourselves

It may be better to follow a more modular approach for architecture. For example:

.
├── bin
├── docker-compose.yml
├── lib
│   └── services
│       ├── httpd
│       │   ├── docker-compose.httpd.yml
│       │   └── etc
│       │       └── httpd.conf
│       ├── mysql
│       │   ├── docker-compose.mysql.yml
│       │   ├── etc
│       │   │   └── mysql.conf
│       │   └── lib
│       │       └── data
│       ├── node
│       │   ├── docker-compose.node.yml
│       │   └── lib
│       │       └── npm-packages
│       └── php
│           ├── docker-compose.php.yml
│           ├── etc
│           │   └── php.ini
│           └── lib
├── Makefile
├── README.md
└── tmp

# docker-compose.yml
version: "2"
services:
  httpd:
    extends:
      file: 'services/httpd/docker-compose.httpd.yml'
      service: httpd

This will make it easier for scaffolding and will just generally be tidier.

Documentation needs to be added describing what this project is about and how to use it.

It would be very helpful to create a scaffold tool that automate the following tasks:

• Specify services, eg: MySQL, Mail, etc.
• Allow bundled services to have their own scaffold system, eg: Apache to set project domains

This isn't being used and should be removed

Would be nice to automate the new project process. I would prefer this not not be installed globally, somehow.

This can be as simple as adding this to docker-compose.yml:

 solr:
    image: solr:6
    ports:
      - "8983"
    volumes:
      - ./lib/solr:/opt/solr/server/solr/mycores
    entrypoint:
      - docker-entrypoint.sh
      - solr-precreate
      - drupal

Add MySQL configuration to increase resource allocation:

# /etc/mysql/conf.d/config-file.cnf

[mysqld]
# 128M
max_allowed_packet=128000000

When creating a new build with:

# Create new build and commit to environment.
mkdir -p src/docroot
git init src
echo "<?php phpinfo();" >> src/docroot/index.php
git -C src add --all && git -C src commit -m "Create build"

This needs to be implemented separately as a git sub module.