This article mainly introduces the construction based on the Docker PHP development Environment Detailed tutorial, Docker is the current virtual machine technology best choice, needs the friend may refer to under
Now many developers use vagrant to manage their virtual machine development environment, vagrant is really cool, but there are a number of drawbacks (the main thing is that it takes up too much resources). After container technology, Docker, and more class Docker technologies emerge, it becomes easier to solve the problem.
Legal Disclaimer
Because of the way boot2docker works, the method described in this article may not function correctly in your environment. If you need to share folders to the Docker container in a non-Linux environment, you need to be aware of additional details. Later I will write an article specifically to introduce the actual problems encountered.
How to be a good development environment
First of all, we need to know what is a good development environment, for me, a good development environment needs to have the following characteristics:
Free to use. I must be free to delete and create a new environment.
Quick Start. I want to use it to work, it can be used immediately.
Easy to update. Things are changing very quickly in our industry and it must make it easy for me to update my development environment to a new version of the software.
And Docker all support these characteristics, even more. You can almost instantly destroy and reconstruct the container, and the update environment only needs to reconstruct the image you are currently using.
What is the PHP development environment
Web applications are complex, PHP development environment needs a lot of things, in order to ensure the simplicity of the environment, need to do a variety of restrictions.
We use Nginx, PHP5-FPM, MySQL to run the Synmfony project.
Pet and cattle
The other point we want to discuss is whether we want to deploy the development environment in multiple containers or single containers. There are advantages to each of the two ways:
Single containers are easy to distribute and maintain. Because they are independent, everything runs in the same container, which is like a virtual machine. But it also means that you need to rebuild the entire container when you want to upgrade something like PHP's new version.
Multiple containers can provide better modularity when adding components. Because each container contains part of the stack: Web, PHP, MySQL, and so on, you can expand each service individually or add services, and you don't need to rebuild everything.
Because I'm lazy, plus I need to put something else in my notebook, so here we only describe the method of a single container.
Initialization of the project
The first thing to do is to initialize a new Symfony project. The recommended method is to use the composer Create-project command. Composer could have been installed on the workstation, but that was too easy. This time we use it through Docker.
I sent an article about the Docker command earlier: Make Docker commands (well, I lied, I wrote it in this article, and thought it would be better to be independent).
Anyway, you can read it. Next, if you don't have the composer command, you can create a composer alias of your own.
?
1 |
$ alias composer= "Docker run-i-t-v $PWD:/srv ubermuda/composer" |
Now you can initialize the Symfony project:
?
1 |
$ composer Create-project Symfony/framwork-standard-edition Someproject |
It's awesome! Here's some real work.
Container
It is fairly easy to build a self-contained container that runs a standard Symfony project, simply by installing the common Nginx, PHP5-FPM, and Mysql-server, and then throwing in the prepared Nginx virtual host configuration file, Copy some of the configuration files and get in.
The source code of this container can be found in the Ubermuda/docker-symfony warehouse on GitHub. Dockerfile is the configuration file that Docker to use to build mirrors, let's look at:
?
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21-22 |
From Debian:wheezy ENV debian_frontend noninteractive RUN apt-get update-y RUN apt-get install-y nginx php5-fpm -mysqlnd php5-cli mysql-server Supervisor RUN sed-e ' s/;d aemonize = yes/daemonize = no/'-i/etc/php5/fpm/php-fpm.conf Run sed-e ' s/;listen.owner/listen.owner/'-i/etc/php5/fpm/pool.d/www.conf run sed-e ' s/;listen.group/listen.group/'- I/etc/php5/fpm/pool.d/www.conf RUN echo "Ndaemon off;" >>/etc/nginx/nginx.conf ADD vhost.conf/etc/nginx/sites-a Vailable/default Add supervisor.conf/etc/supervisor/conf.d/supervisor.conf Add init.sh/init.sh EXPOSE 3306 VOLUME ["/srv"] Workdir/srv CMD ["/usr/bin/supervisord"] |
We started by extending Debian:wheezy this base image and then configured Nginx and PHP5-FPM through a series of SED commands.
Copy code code as follows:
RUN sed-e ' s/;d aemonize = yes/daemonize = no/'-i/etc/php5/fpm/php-fpm.conf
RUN sed-e ' s/;listen.owner/listen.owner/'-i/etc/php5/fpm/pool.d/www.conf
RUN sed-e ' s/;listen.group/listen.group/'-i/etc/php5/fpm/pool.d/www.conf
RUN echo "Ndaemon off;" >>/etc/nginx/nginx.conf
We're going to do two things here. First configure PHP5-FPM and Nginx to run them in the foreground so Supervisord can track them.
The PHP5-FPM is then configured to run Web-server with the specified user and to handle the file permissions.
Next you need to install a set of configuration files, first of all, the Nginx virtual host configuration file vhost.conf:
?
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19-20 |
server {Listen 80; server_name _; Access_log/var/log/nginx/access.log; Error_log/var/log/nginx/error.log; Root/srv/web; Index app_dev.php; Location/{try_files $uri $uri//app_dev.php $query _string;} Location ~ [^/].php (/|$) {Fastcgi_pass unix:/var/run/php5-fpm.sock; include Fastcgi_params;}} |
Since we don't need a domain name, we set the server_name _ (a bit like Perl's $_ placeholder variable) and configure the root directory (document root) as/svr/web, and we'll deploy the application under/srv, and the rest is the standard Mginx + PHP5-FPM configuration.
Because a container can only run one program at a time, we need supervisord (or any other process manager, but I prefer supervisord). Luckily, this process manager produces all the processes we need! The following is a short Supervisord configuration:
?
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16-17 |
[Supervisord] nodaemon=true [Program:nginx] Command=/usr/sbin/nginx [PROGRAM:PHP5-FPM] command=/usr/sbin/php5-fpm [P Rogram:mysql] Command=/usr/bin/mysqld_safe [program:init] command=/init.sh autorestart=false redirect_stderr=true Redirect_stdout=/srv/app/logs/init.log |
What we need to do here is define all the services, plus a special program:init process, which is not a real service, but an original way to run the startup script.
The problem with this startup script is that it usually needs to start some services first. For example, you might want to initialize some database tables, but only if you have to run MySQL first, one possible solution is to start MySQL in the startup script, then initialize the table, and then, to prevent the process from affecting the Supervisord, you need to stop MySQL and finally start Supervisord.
Such a script would look something like the following:
?
1 2 3 4 5 |
/etc/init.d/mysql start app/console doctrine:schema:update--force/etc/init.d/mysql stop Exec/usr/bin/supervisord |
It looks ugly, there are wood, I change the way, let supervisor to run it and never reboot.
The actual init.sh script is as follows:
?
1 2 3 4 5 6 7 8 9 10 11 12 13 14-15 16 |
#!/bin/bash ret=1 while [[Ret-ne 0]]; do sleep 1; Mysql-e ' exit ' >/dev/null 2>&1; Ret=$? Done Db_name=${db_name:-symfony} mysqladmin-u root Create $DB _name if [-N "$INIT"]; then/srv/$INIT fi |
The script waits for MySQL to start, then creates DB based on the environment variable db_name, defaults to Symfony, finds the script to run in the INIT environment variable, and tries to run it. The end of this article shows how to use these environment variables.
Building and running mirrors
Everything is only due to the East wind. We also want to build symfony docker mirrors, using the Docker builds command:
?
1 2 |
$ cd Docker-symfony $ docker build-t symfony. |
Now, you can use it to run your Symfony project:
?
1 2 |
$ cd Someproject $ docker run-i-t-p-v $PWD:/srv symfony |
Let's take a look at the sequence of options:
-I initiate interactive (interactive) mode, that is, STDIO (standard input and output) is connected to your current terminal. It is useful when you want to receive a log or send a signal to a process.
-T creates a virtual TTY for the container, which is a good base friend with-I and is usually used together.
-P tells the Docker daemon to publish all the specified ports, in this case, Port 80.
-V $PWD:/srv mounts The current directory to the/srv directory of the container. Mount a directory to make the contents of the directory available to the target mount point.
Now you remember the db_name and INIT environment variables mentioned earlier, why use them: to customize your environment. Basically you can set the environment variable in the container by Docker Run's-e option, and the startup script gets the environment variable, so if your DB name is Some_project_dev, you can run the container like this:
?
1 |
$ docker run-i-t-p-v $PWD:/srv-e Db_name=some_project_dev symfony |
The INIT environment variable is more powerful, allowing you to run the specified script at startup. For example, you have a Bin/setup script that runs the composer Install command and sets the database schema:
?
1 2 3 |
#!/bin/bash Composer Install App/console doctrine:schema:update--force |
Run it with-e:
?
1 2 3 4 |
$ docker run-i-t-p-v $PWD:/srv-e db_name=some_project_dev-e Init=bin/setup |
Note that the-e option can be used more than once in Docer run and looks pretty cool. In addition, your startup script requires executable permissions (chmod +x).
Now we send the request through the curl to the container to check if everything is working as expected. First, we need to take the Docker map to the container's 80-port public port, using the Docker Port command:
?
1 2 |
$ docker Port $ (Docker PS-AQL 1) # 80 0.0.0.0:49153 |
Docker PS-AQL 1 is a handy command to easily retrieve the ID of the last container, in our case, Docker maps the container's 80 ports to 49153 ports. Let's have a look curl.
?
1 |
$ Curl http://localhost:49153 |
?
1 |
You are are not allowed to access this file. Check app_dev.php for the more information. |
When we do not access the dev controller from localhost (translator Note: container localhost), we get the default error message of Symfony, which is normal, because we are not sending the curl request from inside the container, so You can safely remove these rows from the front-end controller web/app_dev.php.
?
1 2 3 4 5 6 7 8 9 |
This check prevents access to the debug front controllers that are deployed by accident to production. Feel free to remove this, extend it, or make something more sophisticated. if (Isset ($_server[' http_client_ip ')) | | isset ($_server[' http_x_forwarded_for ']) | |! ( In_array (@$_server[' remote_addr '), Array (' 127.0.0.1 ', ' fe80::1 ', ':: 1 ')) | | Php_sapi_name () = = = ' Cli-server ')) {header (' http/1.0 403 Forbidden '); exit (' You are not allowed to access this file. Check '. basename (__file__). ' For more information '); } |
These lines prevent any access to the dev controller from anywhere outside localhost.
You can now work properly when you are curl, or visit http://localhost:49153/in a browser: