Deployer executes a set of commands on the target server to build your project and enable the newly built version. A typical deployment process with Deployer involves SSHing into the target machine, where it performs a Git checkout of the project, installs dependencies via Composer, runs build commands, and possibly triggers some database migrations. When everything is successful, it will symlink the webroot to the new release.

On some servers, however, there are limitations that make this process unfeasible. For instance, you can’t install Composer, Git isn’t available, the CLI PHP version is different and can’t be changed, or certain asset-building processes aren’t possible because Node.js isn’t installed. This is often the case with shared hosting.

The strategy, therefore, is to build the project locally and upload it to the target machine.
In Deployer 6 there was a buildIn mechanism for building your project on the local host.
However with Deployer version 7 this has been removed and building your project locally has become a bit more fiddly.

With Deployer 6 you could just use the local() method on a task and set the deploy_path to a local dir.

task('build', function () {
    set('deploy_path', __DIR__ . '/.build');
    invoke('deploy:prepare');
    invoke('deploy:release');
    invoke('deploy:update_code');
    invoke('deploy:vendors');
    invoke('deploy:clear_paths');
    invoke('deploy:symlink');
})->local();

Then you could combine this with an upload task in a deploy task an you are done.

task('upload', function () {
     upload(__DIR__ . "/.build/current/", '{{release_path}}', ['--links']);
 });

 task('deploy', [
     'build',
     'upload',
     'cleanup',
     'success'
 ]);

See here for the docs of Deployer 6:
https://deployer.org/docs/6.x/advanced/deploy-strategies#build-server

Since Deployer 7, however, the local() method was removed. Instead, there is now a localhost() method, which defines a host for local builds. Additionally, you still need to define the remote host as the target destination for the upload.
However, you cannot specify a single task to run on a specific host, and therefore you cannot combine tasks for localhost and the remote host within a single task.

To build the project, we now need two separate tasks.
I managed to make it work with two tasks and two hosts: one for local build and one that takes the fresh local build and uploads it to the remote host.

localhost('local')->set('deploy_path', __DIR__ . '/.build');

host('remote')
    ->setHostname('server-host.com')
    ->set('remote_user', 'user')
    ->set('deploy_path', '/www/blog')
    ->set('http_user', 'user');
....

task('build', function () {
    // build it
})->once();

task('upload', function () {
    upload(__DIR__ . "/.build/current/", '{{deploy_path}}', ['--links']);
});

Then I simply run two separate commands: one for building on the local host and one for uploading to the remote host.

vendor/bin/dep build local
vendor/bin/dep upload remote

Not as convenient as previously but it works. :)

See this issue for context: https://github.com/deployphp/deployer/issues/2838

There are several ways to import the data in your docker-compose setup.

1. Using a volume for import data
2. Using mysql client from commandline with docker-compose exec
3. Using phpmyadmin in docker-compose setup
4. Using a mysql GUI client on the host and connect to the DB in the Docker container

So let’s see how we can do this:

1. Using a volume for import data

This applies to both official Mysql and MariaDB official images.
These have builtin import mechanism to import data.
To quote from the docs:

Furthermore, it will execute files with extensions .sh, .sql and .sql.gz that are found in /docker-entrypoint-initdb.d. Files will be executed in alphabetical order. You can easily populate your mysql services by mounting a SQL dump into that directory

So all dumps that are found in the /docker-entrypoint-initdb.d directory of the image will be imported unless the database already contains data.

So let’s add this volume to our docker-compose.yaml

volumes: - ./database_dump.sql:/docker-entrypoint-initdb.d/datadump.sql

On next docker-compose up the data will be imported in your empty database.
You will see something like this in your docker-compose logs:

2023-02-06 15:40:16+00:00 [Note] [Entrypoint]: /usr/local/bin/docker-entrypoint.sh: running /docker-entrypoint-initdb.d/database_dump.sql

Note: if there is already data in the database you need to clear the data first by f.e. clearing the volume, otherwise the import will not start:
You can clear all volumes of your docker-compose setup with (caution: this will clear all volumes, not just the database volume):

docker-compose down -v

2. Using mysql client from commandline with docker-compose exec

With this one liner you can import a SQL dump from a docker image that has a MySql/MariaDB client installed and are linked to the DB container:

docker-compose exec my-app bash -c "mysql -u root -h mysql --password=root database < database_dump.sql"

This will execute the application image and import the data with the mysql client which connects to the host mysql which is the linked mysql container.

3. Use phpmyadmin in docker-compose setup

If the above is too consolish then you also can just add a phpmyaadmin container in your docker-compose setup and administer the database with a GUI from the browser.

  myproject_phpmyadmin:
	image: phpmyadmin/phpmyadmin:latest
	ports:
	  - 8080:80
	environment:
	  PMA_HOST: myproject_mysql

Then you can just open http://localhost:8080 in the browser and log into to Phpmyadmin.
To import data go to the import tab and upload the dump file.

4. Using a mysql GUI client on the host and connect to the DB in the Docker container

For this approach you just need to open a port in the database container to the outside and use this port with localhost in the settings of your database client.

  myproject_mysql:
    image: mysql:5.7
    hostname: mysql.${DOMAIN}
    container_name: ${CONTAINER_NAME}.mysql
      volumes:
	- ${PWD}/data/mysql/:/var/lib/mysql
	- ./container/mysql/my.cnf:/etc/mysql/conf.d/z_my.cnf
    ports: # open the mysql port to the host
      - "3306:3306"
    environment:
  ...

See this screenshot from IntellIj’s PHPStorm Database tool:

From my experience these clients are very good to check data but not so good for import, at least I had rather poor experience in the PHPStorm DB Tool.
So going consolish on imports is recommended :)

First choose the namespace you want to check the secrets in by typing a colon and namespace

:namespace

Then choose your namespace by navigating with your arrow down key and press return when on the desired namespace.

Then type a colon and type ‘secrets’:

:secrets

Then choose your secret by navigating with your arrow down key and press return when on the desired secret.

When secret is selected press x and k9s will display the decrypted secrets.

Leave the decrypted display again by pressing Escape key.

Unknown MySQL server host <mysql-service-name>

… and you dont know why because everything seems to be correct.

Then you might have an upgrade problem with mysql because you are reusing an old volume that was created for another mysql version.
This can happen when you use a unspecified tag as mysql:latest (not recommended anyway) and there was a version bump in the official mysql image.
Or you upgraded the mysql container yourself, f.e. from mysql:5.6 to mysql:5.7 and you are reusing the data volume with the mysql files.

When you check the startup logs you might see that mysql container is shutting down after startup because of an error like this:

Can't open the mysql.plugin table. Please run mysql_upgrade to create it.

You can run the upgrade command in the container:

docker exec -it mysql_container_name bash -c "mysql_upgrade -uroot -proot"

Or simply delete the volume and recreate it.
Note: the data will unfortunatly be lost. So better dump the data before deleting the volume and reimport it.
In my case its no problem because im starting a new project anyway.

To delete the volume you can:

docker volume rm <volume id>

Or just delete the data dir:

rm -rf ./data/mysql

Then restart your setup so the mysql container recreates the databases:

docker-compose up

and mysql is working again and the application is able to connect. :)

ERROR: for docker_myproject_phpmyadmin_1 Cannot start service mg_myproject_phpmyadmin: network 15dff95a23808fe9d14b3dae71c0daeaa8b274c90566baa5beff37f3738033b6 not found

For some reason the networks were deleted and docker-compose doesnt automatically recreate networks unless you tell so by forcing docker to recreate containers:

docker-compose up --force-recreate

Solution came from this issue:
https://github.com/docker/compose/issues/5745#issuecomment-370031631

Probably i have to explicitly declare the networks to prevent mixups between projects.
Though i thought this would not be necessary…

Update: Today i would rather use the IntelliJ Database Tool for Sqlite administration.

But since Adminer is a popular hacking target they introduced a feature that does not allow to run adminer without a password, out of the box.
Sqlite database usually runs without password and dang, workaround needed!

So we need to add a plugin to adminer that allows password-less login and extend the official Adminer Docker image to include the plugin.

We add a script that loads the official password-less-login plugin and copy it to the plugins-enabled folder of the Adminer image

login-password-less.php:

<?php
require_once('plugins/login-password-less.php');

/** Set allowed password
 * @param string result of password_hash
 */
return new AdminerLoginPasswordLess(
    $password_hash = password_hash("admin", PASSWORD_DEFAULT)
);

Dockerfile:

FROM adminer
USER root
COPY login-password-less.php /var/www/html/plugins-enabled/login-password-less.php
#USER adminer # we run as root because of permissions problems on db file with the volume

In docker-compose.yml:

version: "3"
services:
  app:
    build: ./php
      - mailcatcher
    volumes:
      - "../:/app:rw"
      - "./php/cli/php.ini:/etc/php/7.3/cli/php.ini:ro"
      - "./php/fpm/php.ini:/etc/php/7.3/fpm/php.ini:ro"

  nginx:
    build: ./nginx
    depends_on:
      - app
    command: /bin/sh -c "nginx -g 'daemon off;'"
    volumes:
      - "..:/app:rw"
      - ./nginx/default.conf:/etc/nginx/conf.d/default.conf:ro
    ports:
      - '8088:80'

  adminer:
    build: ./adminer
    restart: unless-stopped
    volumes:
      - "..:/app:rw"
    ports:
      - 8080:8080

File tree:

• adminer
  – Dockerfile
  – login-password-less.php
• nginx
  …
• php
  …
• docker-compose.yml

Note that since docker-compose.yml version 3 the volumes_from directive was removed in favor of top level volumes to share volumes across images. However this implementation is imho rather weird, so i jut duplicated the volumes declaration in the App container and Adminer container.
Feels rather wrong but thats all i could come up with. Any advice here is welcome.

Now that this is done we can open the Sqlite3 database with the pseudo-password “admin” and manage the database.

After all you could also just copy the one-file Adminer with plugin to the php container and run it from within the php container. Just adjust your Nginx config to allow calling the file directly and take care to not deploy Adminer to live.
There is also a project that bundles the plugin with Adminer to one file: https://github.com/FrancoisCapon/LoginToASqlite3DatabaseWithoutCredentialsWithAdminer/blob/master/build-adminer-4-sqlite3-into-one-file.sh

When working with this constellation you will sooner or later come across the i18n topic. Most likely you would want to share translations between front- and backend. So that you could keep translations in one single location while using it for frontend templates as well as server-side error messages etc.

One approach would be to store translations in the symfony yml or xml files and deliver those to the frontend via an api endpoint.
Given that front- and backend-code run on the same server, there is an even simpler solution.

Since symfony does not only read yml or xml but also translations in the json format, you can simply keep translations in the frontend and read those files with symfony directly.

All you need to do to achieve this is symlink the angular translation files to your symfony translation catalog location.

messages.de.json -> ../../../web/ng/I18n/de_DE.json
messages.en.json -> ../../../web/ng/I18n/en_EN.json

Disclaimer: This works only for relatively simple use cases with no complex translation patterns. But hey…

When I first tried docker (docker-toolbox for mac) I was really disappointed how slow symfony apps ran inside the container.

I did a bit of research (didn’t completely get it though) – but most of the speed issues that people experience seem to be related to the rather slow file system access in mounted folders.

That’s where dlite really shines.
It’s an app that uses some sort of alternative to virtualbox etc. which has significant speed advantages.

I highly recommend you give it a try if you’re developing with docker in OSX.
Installation with homebrew is quite simple:

brew install dlite
dlite stop && dlite update -v 2.3.0 && dlite start
brew install docker
brew install docker-compose

Another thing I found quite challenging was setting up permissions when running symfony inside docker.
I found a couple of tutorials on that but none of those seemed to really work with my setup.

You could use data containers for the cache and log folders and don’t have any permission problems.
Or just use some internal folder `/tmp/myapp/cache` or `/dev/shm/myapp` (the latter really is fast…).

But any of those approaches will make it difficult to access the cache files from the host.
(I use PHPStorm with the symfony plugin, which relies on parsing some cache files)
It also doesn’t solve the problem of persmissions for the `/web` folders, when installing assets or write to any data folders you also wan’t to mount from the host filesystem.

I have not found a really elegant solution for that, but there’s a workaround which does work magic:

You can set uid of the www-data inside the container your host users’ uid.
Something like `RUN usermod -u 501 www-data` inside your webserver Dockerfile should do the trick for your default user on mac. You can then log into the container and run symfony commands as www-data and have no problems with accessing files from host filesystem, command-line or the webserver.

We put together a docker setup for symfony development, which should work across different operating systems.

https://github.com/nerdpress-org/docker-sf3/

So as a quickstart, after installing docker & dlite just run:

git clone https://github.com/nerdpress-org/docker-sf3.git docker-sf3
cp -r docker-sf3/docker /path/to/your/symfony-project/
cd /path/to/your/symfony-project/docker
sh ./docker.sh -l

So i have this uncritical smaller API app where the hosting has git, ssh access and i am in full control and i decided too keep it simple.

For deploy i login via ssh and make a git pull too fetch the code.
Now we need to make a composer install, if the composer.lock has changes to fetch all php dependencies.
Therefor i found a handy bash script, tweaked it a bit and installed it as post-merge git hook.

Install the hook:

cd project
nano .git/hooks/post-merge #paste & edit the script
chmod 775 .git/hooks/post-merge 

What it does?
After all code from the git pull is merged into the working tree, the hook checks if the composer.lock has changed. If so it will run a composer install.
Note that it runs with –no-dev since we are on production and dont need f.e. phpunit there.

I know you know, but let it be said again: run composer install not composer update, as you never should run composer update on production, read why here.

So here is the bash:

#/usr/bin/env bash
# MIT © Sindre Sorhus - sindresorhus.com
# forked by Gianluca Guarini
# phponly by Ivo Bathke ;)
 
changed_files="$(git diff-tree -r --name-only --no-commit-id ORIG_HEAD HEAD)"
 
check_run() {
  echo "$changed_files" | grep --quiet "$1" && eval "$2"
}
 
# `composer install` if the `composer.lock` file gets changed
# to update all the php dependencies
check_run composer.lock "composer install --no-dev"

I forked it from here, that forked from there.

its much nicer to use the DirectoryIndex in your URL and not having the web_app.php, thats the aesthetics.
But it also avoids having some hassle with ajax urls which are defined absolute in some scripts like
url: /myajax/call.json

The Environment can be changed in the .env.php file which just returns the Environment value:

<?php
return $env = 'dev';

Personally i dont mind changing the Env in the code rather than in the url, while in development.
It might be a tick more far away but its rather uncommon anyway and it would be more effort to change the vhost DirectoryIndex on web_dev.php and prod everytime to get a clean url.
(thanks max & joshi)

2. resolve console and webserver user conflict for cache
Different to Symfony 1.x Symfony2 assumes a more sophisticated User Managment on your machine for Security reasons, which absolutly makes sense. Read more about it here:http://symfony.com/doc/current/book/installation.html#configuration-and-setup
This means you have to adjust the rights for the webserver- and for the console user that both can create and delete the cache.
This requires some admin skills which might be a bit too much for starters.
And some people start wondering why the

php app/console cache:clear

command wont work and start using

rm -rf app/cache/*

in desperation.

To fix this Symfony2 recommends as a ‘hotfix’ to uncomment the

umask(0000);

part on top of your bootstrap files.
So simply uncomment the line in app_dev.php ( if you use the one from above its already done :) ) and in app/console.
Thats alright for local setup, for production go and talk to your admin of trust or live the life of adventure.

3. make a local config that can be placed in gitignore
Here you can store config parameters and overwrite common ones to fit your local setup. Put it in the gitignore so your fellow devs can do the same.
Therefor we need to hack the AppKernel.php and redefine the registerContainerConfiguration method like so.

public function registerContainerConfiguration(LoaderInterface $loader) {

        if ($this->getEnvironment() == 'dev') {
            $extrafiles = array(
                __DIR__ . '/config/config_local.yml',
            );
            foreach ($extrafiles as $filename) {
                if (file_exists($filename) && is_readable($filename)) {
                    $loader->load($filename);
                }
            }
        } else {
            $loader->load(__DIR__ . '/config/config_' . $this->getEnvironment() . '.yml');
        }
}

Read more about it:
http://stackoverflow.com/questions/7338767/can-i-include-an-optional-config-file-in-symfony2/10336451#10336451

Now have fun with bundles & services.