Websites created with craftman cannot be migrated

[nicbou]

I hoped to get an environment started with Craft, then just move the whole website to production when it's ready. The main promise of docker is that you have consistent, portable application environments. However, it seems like Craftman hardcodes a lot of information and is not really deployment-friendly.

• The port is hard-coded in the docker file and config. It's different in development because of Brand new install just won't load (timeout) #15
• Debug mode is hard-coded to ON in the docker file
• Unless the directories have specially crafted permissions, Apache will silently fail because it can't read the .htaccess file.
• Once the permissions are fixed, I just get a "Service Unavailable" page. The rest of the website is missing.

In the end, I decided to use Craftman to recreate an empty site in production, but then I hit #3. I'm not sure if I am using Craftman correctly.

[nicbou]

I would also like to add that craftman reconfigure breaks permissions on a directory whose permissions I had just fixed.

[gabrielmoreira]

Sorry for the delay to respond. Most of the problem is the lack of documentation.

1. I never intended to use craftman for production, and I did not document it well. All generated docker files are for development environment.

Making a production environment varies greatly according to the architecture of each company. Some use clustered environments, others do not. Some with Docker Swarm, others with Kubernetes, Amazon ECS, etc ... I think each of these environments could be supported through the craftman plugins, just like craftman heroku: prepare. In the same way, creating the production Docker and Docker Compose files could be via plugins.

2. I do not have OSX, it's difficult for me to test, and there are still some issues with the docker port problem. The craftman's construction was done completely on Linux. It works well enough for me and some friends. But they all use Linux as well.

3. File permissions is a problem even in our case, but I've not yet had time to find the right solution for local development environment.

I have little time available to contribute. Where possible, I count on the contribution of the open source community by sending pull requests. When someone makes a fork, and improving the code is always rewarding to see.

Once again, I apologize for the difficulty you had, and thank you for the feedback. When I have some time off, I'll try to take a look.

If you can help by sending some code or documentation fix, or even rearranging the documentation to make more sense, I'll take a look at the merge.

[nicbou]

Hi Gabriel,

I found Craftman through the older project of yours that's deprecated by it, so I thought it matched my Google search for a Craft docker image. I was looking for a way to make development and deployment of Craft sites easier because I hate setting up LAMP servers.

The main issue is that Craftman does not really use Docker as intended: it installs the dependencies on the host machine. The dependencies should be installed on the Docker container using a Dockerfile.

This is what I ended up doing. I created a Dockerfile that does what 010_dependencies.sh does, but inside the Docker container. The host machine is unaffected by this, so the image works flawlessly on OS X and Linux.

Of course, there are still permission issues, but only if you manually copy files. It works just fine if you deploy with git. The URL is not anywhere in the code, so the only difference between localhost and production is that the CRAFT_DEVMODE environment variable is set to true locally.

Here is my docker-compose.yml:

craft:
  build: site
  links:
    - "mysql:mysql"
  volumes:
    - "./site/www:/var/www"  # The website is under /site/www in git. It contains the craft and html dirs
  environment:
    - CRAFT_DEVMODE
  ports:
    - 80:80  # Somehow, this works fine on OS X o_0
mysql:
  image: "mariadb:10.1"
  volumes_from:
    - "mysql_data"
  environment:
    - MYSQL_DATABASE=craft
    - MYSQL_ALLOW_EMPTY_PASSWORD=yes
mysql_data:
  image: "debian:jessie"
  volumes:
    - /var/lib/mysql

Here is my Dockerfile:

FROM php:7-apache
MAINTAINER Nicolas Bouliane

RUN apt-get update
RUN apt-get install -y --no-install-recommends \
        libfreetype6-dev \
        libjpeg62-turbo-dev \
        libmcrypt-dev \
        libpng12-dev \
        libmagickwand-dev \
        curl \
        wget

RUN pecl install -f imagick
RUN docker-php-ext-configure gd --with-freetype-dir=/usr/include/ --with-jpeg-dir=/usr/include/
RUN docker-php-ext-install -j$(nproc) iconv mcrypt gd mbstring pdo pdo_mysql zip
RUN docker-php-ext-enable imagick

RUN curl -sS https://getcomposer.org/installer | php

RUN a2enmod rewrite setenvif deflate headers filter expires

VOLUME ["/var/www"]

CMD ["apache2-foreground"]

I also made two utility scripts to replace mysql:backup and restore. They take the .sql file path as an argument:

#!/usr/bin/env bash
MYSQL_DATABASE_NAME=craft
MYSQL_DUMP_FILE=$1

MYSQL_CONTAINER=`COLUMNS=1000 docker-compose ps mysql | grep mysqld | cut -f 1 -d ' '`

mysql_cmd()
{
	CMD="${@:-TERM=dumb mysql $MYSQL_DATABASE_NAME}"
	docker exec -i -t "${MYSQL_CONTAINER}" sh -i -c "$CMD"
}

mkdir -p "$(dirname "$MYSQL_DUMP_FILE")"

echo "Dumping data from MySQL..."
mysql_cmd mysqldump craft > $MYSQL_DUMP_FILE
echo "Database backup done."

#!/usr/bin/env bash
MYSQL_DATABASE_NAME=craft
MYSQL_DUMP_FILE=$1

MYSQL_CONTAINER=`COLUMNS=1000 docker-compose ps mysql | grep mysqld | cut -f 1 -d ' '`

mysql_cmd()
{
	CMD="${@:-TERM=dumb mysql $MYSQL_DATABASE_NAME}"
	docker exec -i -t "${MYSQL_CONTAINER}" sh -i -c "$CMD"
}

echo "Copying dump file inside container..."
docker cp "${MYSQL_DUMP_FILE}" "${MYSQL_CONTAINER}:/tmp"

echo "Importing SQL..."
mysql_cmd "mysql craft -e 'source /tmp/$MYSQL_DUMP_FILE'"

echo "Removing all temporary files..."
docker exec -i -t "${MYSQL_CONTAINER}" sh -i -c "rm /tmp/$MYSQL_DUMP_FILE"

echo "SQL restore completed"