One place for hosting & domains

      How to Install Nginx on FreeBSD 11.2


      Introduction

      Nginx is one of the most popular web servers in the world, known for its frequent use as a load balancer and reverse proxy. It’s more resource-friendly than Apache, and many of the largest and most highly trafficked sites on the internet depend on Nginx to serve their content.

      In this guide, we will demonstrate how to install Nginx on a FreeBSD 11.2 server.

      Prerequisites

      Before beginning this guide, you will need access to a server running FreeBSD. This guide was written specifically with a server running FreeBSD 11.2 in mind, although it should also work on older, supported versions of the operating system.

      If you’re new to working with FreeBSD, you may find it helpful to customize this server by following these instructions.

      Additionally, if you plan to set up a domain name for this server, you will need the following:

      • A registered domain name that you own and control. If you do not already have a registered domain name, you may register one with one of the many domain name registrars out there (e.g. Namecheap, GoDaddy, etc.).
      • A DNS A Record that points your domain to the public IP address of your server. You can follow this hostname tutorial for details on how to add them.

      Step 1 — Installing Nginx

      To begin, we will install Nginx using pkg, FreeBSD’s built-in binary package management tool. The following command will update your local copy of the available packages and then install the nginx package:

      If this is your first time running pkg, it will prompt you to confirm that you allow it to bootstrap itself. To do this, press y and then ENTER. Then, when prompted, confirm that you approve the installation of the nginx package by pressing y and then ENTER once again.

      If you are using either the csh or tcsh shell, make sure to run the rehash command. This makes the shell aware of the new applications you installed:

      Note: If you aren't sure which shell you're currently using, you can check with the following command:

      The output will show the file path of the shell program currently in use:

      Output

      /bin/tcsh

      Nginx is now installed on your server, but it is not yet running. In the next step, we'll enable Nginx to start running every time the server boots up and start it for this session, as well as walk through the process of securing the server by setting up a firewall with IPFW.

      Step 2 — Enabling the Nginx Service and Setting Up a Firewall with IPFW

      In order for FreeBSD to start Nginx as a conventional service, you have to tell FreeBSD that you want to enable it. This will allow you to manage it like any other service, rather than as a standalone application, and will also configure FreeBSD to start it up automatically at boot.

      To do this, you first need to know the correct rc parameter to set for the nginx service. rc is a FreeBSD utility that controls the system's automatic boot processes. Scripts for every service available on the system are located in the /usr/local/etc/rc.d directory. These define the parameters that are used to enable each service using the rcvar variable. We can see what each service's rcvar is set to by typing:

      • grep rcvar /usr/local/etc/rc.d/*

      After has been installed, this command will output a listing similar to this:

      Output

      /usr/local/etc/rc.d/cloudconfig:rcvar="cloudinit_enable" /usr/local/etc/rc.d/cloudfinal:rcvar="cloudinit_enable" /usr/local/etc/rc.d/cloudinit:rcvar="cloudinit_enable" /usr/local/etc/rc.d/cloudinitlocal:rcvar="cloudinit_enable" /usr/local/etc/rc.d/nginx:rcvar=nginx_enable /usr/local/etc/rc.d/rsyncd:rcvar=rsyncd_enable

      The parameter that you need to set for the nginx service is highlighted here in this output. The name of the script itself — the last component of the path before the colon — is also helpful to know, as that's the name that FreeBSD uses to refer to the service.

      To enable the nginx service you must add its rcvar to the rc.conf file, which holds the global system configuration information referenced by the startup scripts. Use your preferred editor to open the /etc/rc.conf file with sudo privileges. Here, we'll use ee:

      At the top of the file, there will be a few rcvar parameters already in place. Add the nginx_enable rcvar parameter below these and set it to "YES":

      /etc/rc.conf

      . . .
      sshd_enable="YES"
      nginx_enable="YES"
      
      . . .
      

      While still in the rc.conf file, we will add a few more directives to enable and configure an IPFW firewall. IPFW is a stateful firewall written for FreeBSD. It provides a powerful syntax that allows you to customize security rules for most use cases.

      Directly below the nginx_enable parameter you just added, add the following highlighted lines:

      /etc/rc.conf

      . . .
      nginx_enable="YES"
      firewall_enable="YES"
      firewall_type="workstation"
      firewall_myservices="22/tcp 80/tcp"
      firewall_allowservices="any"
      

      Here’s what each of these directives and their settings do:

      • firewall_enable="YES" — Setting this directive to "YES" enables the firewall to start up whenever the server boots.
      • firewall_type="workstation" — FreeBSD provides several default types of firewalls, each of which have slightly different configurations. By declaring the workstation type, the firewall will only protect this server using stateful rules.
      • firewall_myservices="22/tcp 80/tcp" — The firewall_myservices directive is where you can list the TCP ports you want to allow through the firewall. In this example, we’re specifying ports 22 and 80 to allow SSH and HTTP access to the server, respectively.
      • firewall_allowservices="any" — This allows a machine from any IP address to communicate over the ports specified in the firewall_myservices directive.

      After adding these lines, save the file and close the editor by pressing CTRL + C, typing exit, and then pressing ENTER.

      Then, start the ipfw firewall service. Because this is the first time you're starting the firewall on this server, there's a chance that doing so will cause your server to stall, making it inaccessible over SSH. The following nohup command — which stands for "no hangups" — will start the firewall while preventing stalling and also redirect the standard output and error to a temporary log file:

      • sudo nohup service ipfw start >/tmp/ipfw.log 2>&1

      If you're using either the csh or tcsh shells, though, this redirect will cause Ambiguous output redirect. to appear in your output. If you're using either of these shells, run the following instead to start ipfw:

      • sudo nohup service ipfw start >&/tmp/ipfw.log

      Note: In the future, you can manage the ipfw firewall as you would any other service. For example, to stop, start, and then restart the service, you would run the following commands:

      • sudo service ipfw stop
      • sudo service ipfw start
      • sudo service ipfw restart

      Next, start the nginx service

      Then, to test that Nginx is able to serve content correctly, enter your server's public IP address into the URL bar of your preferred web browser:

      http://your_server_ip
      

      Note: If you aren't sure of your server's public IP address, you can run the following command which will print your server's IP address, as seen from another location on the internet:

      If everything is working correctly, you will see the default Nginx landing page:

      Nginx default page

      This shows that Nginx is installed and running correctly and that it's being allowed through the firewall as expected. There are still a few configuration changes that need to be made, though, in order for it to work with non-default settings or serve content using a domain name.

      Step 3 — Setting Up a Server Block

      When using the Nginx web server, server blocks (similar to virtual hosts in Apache) can be used to encapsulate configuration details and host more than one domain from a single server. We will set up a domain called example.com, but you should replace this with your own domain name. To learn more about setting up a domain name with DigitalOcean, see our Introduction to DigitalOcean DNS.

      Nginx on FreeBSD 11.2 has one server block enabled by default that is configured to serve documents out of a directory at /usr/local/www/nginx. While this works well for a single site, it can become unwieldy if you are hosting multiple sites. Instead of modifying /usr/local/www/nginx, let's create a directory structure within /usr/local/www for our example.com site.

      Create the directory for example.com as follows, using the -p flag to create any necessary parent directories:

      • sudo mkdir -p /usr/local/www/example.com/html

      Next, assign ownership of the directory to the www user, the default Nginx runtime user profile:

      • sudo chown -R www:www /usr/local/www/example.com

      The permissions of your web root should be correct if you haven't modified your umask value, but you can make sure by typing:

      • sudo chmod -R 755 /usr/local/www/example.com

      Next, create a sample index.html page using ee:

      • sudo ee /usr/local/www/example.com/html/index.html

      Inside, add the following sample HTML:

      /usr/local/www/example.com/html/index.html

      <html>
          <head>
              <title>Welcome to Example.com!</title>
          </head>
          <body>
              <h1>Success!  The example.com server block is working!</h1>
          </body>
      </html>
      

      Save and close the file when you are finished.

      In order for Nginx to serve this content, it's necessary to create a server block with the correct directives. Open the main Nginx configuration file. By default, this is held in the /usr/local/etc/nginx/ directory:

      • sudo ee /usr/local/etc/nginx/nginx.conf

      Note: Generally, you want to avoid editing the default nginx.conf file. However, within this same directory, there's a file called nginx.conf-dist, which is identical to the default nginx.conf file. If you ever find that you need to revert with these configuration changes, you can just copy over this file with the following command:

      • sudo cp /usr/local/etc/nginx/nginx.conf-dist /usr/local/etc/nginx/nginx.conf

      When you first open the file, you'll see the following at the very top:

      /usr/local/etc/nginx/nginx.conf

      #user  nobody;
      worker_processes  1;
      
      . . .
      

      Uncomment the user directive by removing the pound sign (#) and then change the user from nobody to www. Then update the worker_processes directive which allows you to select how many worker processes Nginx will use. The optimal value to enter here isn't always obvious or easy to find. Setting it to auto tells Nginx sets it to one worker per CPU core, which will be sufficient in most cases:

      /usr/local/etc/nginx/nginx.conf

      user  www;
      worker_processes  auto;
      . . .
      

      Then scroll down to the server block. With all comments removed, it will look like this:

      /usr/local/etc/nginx/nginx.conf

      . . .
          server {
              listen       80;
              server_name  localhost;
      
              location / {
                  root   /usr/local/www/nginx;
                  index  index.html index.htm;
              }
      
              error_page   500 502 503 504  /50x.html;
      
              location = /50x.html {
                  root   /usr/local/www/nginx-dist;
              }
          }
      

      Delete this entire server block, including all the commented-out lines, and replace it with the following content:

      /usr/local/etc/nginx/nginx.conf

      . . .
          server {
              access_log /var/log/nginx/example.com.access.log;
              error_log /var/log/nginx/example.com.error.log;
              listen       80;
              server_name  example.com www.example.com;
      
              location / {
                  root   /usr/local/www/example.com/html;
                  index  index.html index.htm;
              }
          }
      . . .
      

      Here's what the directives in this server block do:

      • access_log: This directive defines the location of the server's access logs.
      • error_log: This defines the file where Nginx will write its error logs.
      • listen: The listen directive declares what port Nginx should listen in on. In this case, we set it to port 80 so it can listen for HTTP traffic.
      • server_name: Here, point Nginx to your domain name and any aliases you have for it. If you don't have a domain name, point Nginx to your server's public IP address.
      • root: This defines the website document root, which you created earlier in this step.
      • index: This directive defines the files that will be used as an index, and in which order they should be checked.

      All together, with comments removed, the file will look like this:

      /usr/local/letc/nginx/nginx.conf

      user  www;
      worker_processes  1;
      
      events {
          worker_connections  1024;
      }
      
      http {
          include       mime.types;
          default_type  application/octet-stream;
          sendfile        on;
          keepalive_timeout  65;
      
          server {
              access_log /var/log/nginx/example.com.access.log;
              error_log /var/log/nginx/example.com.error.log;
              listen       80;
              server_name  example.com www.example.com;
      
              location / {
                  root   /usr/local/www/example.com;
                  index  index.html index.htm;
              }
      
          }
      
      }
      

      Save and close the file when you are finished. Then, test your configuration file for syntax errors by typing:

      If your configuration file has no detectable syntax errors, you'll see the following output:

      Output

      nginx: the configuration file /usr/local/etc/nginx/nginx.conf syntax is ok nginx: configuration file /usr/local/etc/nginx/nginx.conf test is successful

      If the above command returns with errors, re-open the Nginx configuration file to the location where the error was found and try to fix the problem.

      When your configuration checks out correctly, go ahead and reload the nginx service to enable your changes:

      • sudo service nginx reload

      Nginx should now be serving the content you set up in the index.html file. Test this by navigating to http://example.com, where you should see something like this:

      Nginx first server block

      As a final step, we will go over some commands that will allow you to manage the Nginx service.

      Step 4 — Managing the Nginx Process

      Now that you have your web server up and running, let's review some basic management commands.

      To stop your web server, type:

      To start the web server when it is stopped, type:

      To stop and then start the service again, type:

      • sudo service nginx restart

      If you are simply making configuration changes, you can reload Nginx without dropping any connections. To do this, type:

      • sudo service nginx reload

      Lastly, recall how in Step 2 we enabled the nginx service by adding the nginx_enable="YES" directive to the rc.conf file. If you'd like to disable the nginx service to keep it from starting up when the server boots, you would need to reopen that file and remove that line.

      Conclusion

      You now have a fully functional Nginx web server installed on your machine. From here, you could encrypt your server’s web traffic by enabling HTTPS. To learn how to do this, consult How To Secure Nginx with Let's Encrypt on FreeBSD. You could also install and configure MySQL and PHP which, along with Nginx, would give you a complete FEMP stack.



      Source link

      How To Secure Nginx with NAXSI on Ubuntu 16.04


      The author selected The OWASP Foundation to receive a donation as part of the Write for DOnations program.

      Introduction

      Nginx is a popular, open-source HTTP server and reverse proxy known for its stability, simple configuration, and frugal resource requirements. You can greatly increase the security of your Nginx server by using a module like NAXSI. NAXSI (Nginx Anti XSS & SQL Injection) is a free, third-party Nginx module that provides web application firewall features. NAXSI analyzes, filters, and secures the traffic that comes to your web application, and acts like a DROP-by-default firewall, which means that it blocks all the traffic coming its way unless instructed to specifically allow access.

      The simplicity with which a user can manipulate access is a key feature that differentiates NAXSI from other web application firewalls (WAF) with similar functionality like ModSecurity. Although ModSecurity comes with a rich feature set, it is more difficult to maintain than NAXSI. This makes NAXSI a simple and adaptable choice that provides readily available rules that work well with popular web applications such as WordPress.

      In this tutorial, you will use NAXSI to secure Nginx on your Ubuntu 16.04 server. Since the NAXSI module doesn’t come with the Nginx package by default, you will need to compile Nginx from source with NAXSI. By the end of this tutorial, you will know what kinds of attacks NAXSI can block and how to configure NAXSI rules.

      Prerequisites

      To complete this tutorial, you will need:

      Step 1 — Installing Nginx and NAXSI

      Most of the Nginx modules are not available through repositories, and NAXSI is no exception. Because of this, you will have to manually download and compile Nginx from source with NAXSI.

      First, download Nginx using the following command.

      Note: This tutorial uses version 1.14 of Nginx. To use a more recent version, you can visit the download page and replace the highlighted text in the preceding command with an updated version number. It is recommended to use the latest stable version.

      • wget http://nginx.org/download/nginx-1.14.0.tar.gz

      Next, download NAXSI from the stable 0.56 release on Github.

      Note: This tutorial uses version 0.56 of NAXSI. You can find more recent releases at the NAXSI Github page. It is recommended to use the latest stable version.

      • wget https://github.com/nbs-system/naxsi/archive/0.56.tar.gz -O naxsi

      As you may have noticed, the Nginx repository is a tar archive. You first need to extract it to be able to compile and install it, which you can do by using the tar command.

      • tar -xvf nginx-1.14.0.tar.gz

      In the preceding command, -x specifies the extract utility, -v makes the utility run in verbose mode, and -f indicates the name of the archive file to extract.

      Now that you have extracted the Nginx files, you can move on to extract the NAXSI files using the following command:

      You now have the folders naxsi-0.56 and nginx-1.14.0 in your home directory. Using the files that you just downloaded and extracted, you can compile the Nginx server with NAXSI. Move into your nginx-1.14.0 directory

      In order to compile Nginx from source, you will need the C compiler gcc, the Perl Compatible Regular Expressions library libpcre3-dev, and libssl-dev, which implements the SSL and TLD cryptographic protocols. These dependencies can be added with the apt-get command.

      First, run the following command to make sure you have an updated list of packages.

      Then install the dependencies:

      • sudo apt-get install build-essential libpcre3-dev libssl-dev

      Now that you have all your dependencies, you can compile Nginx from source. In order to prepare Nginx to be compiled from source on your system, execute the following script, which will create the Makefile that shows where to find all necessary dependencies.

      • ./configure
      • --conf-path=/etc/nginx/nginx.conf
      • --add-module=../naxsi-0.56/naxsi_src/
      • --error-log-path=/var/log/nginx/error.log
      • --http-client-body-temp-path=/var/lib/nginx/body
      • --http-fastcgi-temp-path=/var/lib/nginx/fastcgi
      • --http-log-path=/var/log/nginx/access.log
      • --http-proxy-temp-path=/var/lib/nginx/proxy
      • --lock-path=/var/lock/nginx.lock
      • --pid-path=/var/run/nginx.pid
      • --user=www-data
      • --group=www-data
      • --with-http_ssl_module
      • --without-mail_pop3_module
      • --without-mail_smtp_module
      • --without-mail_imap_module
      • --without-http_uwsgi_module
      • --without-http_scgi_module
      • --prefix=/usr

      Each of the lines of the preceding command defines a parameter for the Nginx web server. The most important of these are the --add-module=../naxsi-0.56/naxsi_src/ parameter, which connects the NAXSI module with Nginx, and the --user=www-data and --group=www-data paramaters, which make Nginx run with the user and group privileges of a dedicated user/group called www-data that comes with your Ubuntu 16.04 server. The --with-http_ssl_module parameter enables the Nginx server to use SSL cryptography, and the --without-mail_pop3_module, --without-mail_smtp_module, and --without-mail_imap_module parameters turn off the unneeded mail protocols that would otherwise be automatically included. For further explanation of these parameters, see the official Nginx docs.

      After using the ./configure command, run the make command to enact a series of tasks defined in the Makefile you just created to build the program from the source code.

      When Nginx is built and ready to run, use the make install command as a superuser to copy the built program and its libraries to the correct location on your server.

      Once this succeeds, you will have a compiled version of Nginx with the NAXSI module. In order to get NAXSI to start blocking unwanted traffic, you now need to establish a set of rules that NAXSI will act upon by creating a series of configure files.

      Step 2 — Configuring NAXSI

      The most important part of a firewall's functioning is its rules, which determine how requests are blocked from the server. The basic set of rules that comes by default with NAXSI are called core rules. These rules are meant to search for patterns in parts of a request and to filter out ones that may be attacks. NAXSI core rules are applied globally to the server for signature matching.

      To configure Nginx to use these core rules, copy the naxsi_core.rules file to Nginx config directory.

      • sudo cp ~/naxsi-0.56/naxsi_config/naxsi_core.rules /etc/nginx/

      Now that the core rules are established, add the basic Naxsi rules, which enable and implement the core rules on a per location basis and assign actions for the server to take when a URL request does not satisfy the core rules. Create a file called naxsi.rules inside the /etc/nginx/ directory. To do so, use the following command to open the file in the text editor called nano, or use your text editor of choice.

      • sudo nano /etc/nginx/naxsi.rules

      Add the following block of code that defines some basic firewall rules.

      /etc/nginx/naxsi.rules

       SecRulesEnabled;
       DeniedUrl "/error.html";
      
       ## Check for all the rules
       CheckRule "$SQL >= 8" BLOCK;
       CheckRule "$RFI >= 8" BLOCK;
       CheckRule "$TRAVERSAL >= 4" BLOCK;
       CheckRule "$EVADE >= 4" BLOCK;
       CheckRule "$XSS >= 8" BLOCK;
      

      The preceding code defines the DeniedUrl, which is the URL NAXSI will redirect to when a request is blocked. The file also enables a checklist of different kinds of attacks that NAXSI should block, including SQL injection, cross-site scripting (XSS), and remote file inclusion (RFI). Once you have added the preceding code to the file, save and exit the text editor.

      Since you redirected blocked requests to /error.html, you can now create an error.html file inside /usr/html directory to provide this destination with a landing page. Open up the file in your text editor:

      • sudo nano /usr/html/error.html

      Next, add the following HTML code to the file to make a web page that lets the user know that their request was blocked:

      /usr/html/error.html

      <html>
        <head>
          <title>Blocked By NAXSI</title>
        </head>
        <body>
          <div style="text-align: center">
            <h1>Malicious Request</h1>
            <hr>
            <p>This Request Has Been Blocked By NAXSI.</p>
          </div>
        </body>
      </html>
      

      Save the file and exit the editor.

      Next, open up the Nginx configuration file /etc/nginx/nginx.conf in your text editor.

      • sudo nano /etc/nginx/nginx.conf

      To add the NAXSI configuration files to Nginx's configuration so that the web server knows how to use NAXSI, insert the highlighted lines of code into the http section of the nginx.conf file:

      /etc/nginx/nginx.conf

      . . .
      http {
          include       mime.types;
          include /etc/nginx/naxsi_core.rules;
          include /etc/nginx/conf.d/*.conf;
          include /etc/nginx/sites-enabled/*;
      
      
          default_type  application/octet-stream;
      . . .
      

      Then in the server section of the same file, add the following highlighted line:

      /etc/nginx/nginx.conf

      . . .
          server {
              listen       80;
              server_name  localhost;
      
              #charset koi8-r;
      
              #access_log  logs/host.access.log  main;
      
              location / {
              include /etc/nginx/naxsi.rules;
                  root   html;
                  index  index.html index.htm;
              }
      . . .
      

      Now that you have configured Nginx with the core and basic rules for NAXSI, the firewall will block matching malicious requests when you start the web server. Next, you can write a startup script to ensure that Nginx starts up when you reboot the server.

      Step 3 — Creating the Startup Script for Nginx

      Since you installed Nginx manually, the next step is to create a startup script to make the web server autostart on system reloads.

      This tutorial uses the Systemd software suite to make the script. To do this, you will create a Unit File (see Understanding Systemd Units and Unit Files for further study) to configure how Systemd should start and manage the Nginx service.

      Make a file called nginx.service and open it up in your text editor:

      • sudo nano /lib/systemd/system/nginx.service

      Add the following lines to the file:

      /lib/systemd/system/nginx.service

      [Unit]
      Description=The NGINX HTTP and reverse proxy server
      After=syslog.target network.target remote-fs.target nss-lookup.target
      
      [Service]
      Type=forking
      PIDFile=/run/nginx.pid
      ExecStartPre=/usr/sbin/nginx -t
      ExecStart=/usr/sbin/nginx
      ExecReload=/usr/sbin/nginx -s reload
      ExecStop=/bin/kill -s QUIT $MAINPID
      PrivateTmp=true
      
      [Install]
      WantedBy=multi-user.target
      

      The [Unit] section defines the program that you are configuring, [Service] describes how Nginx should behave on startup, and [Install] provides information about unit installation. Once you add these lines to the nginx.service file, systemd will know how to start Nginx.

      Next, Nginx needs a folder to temporarily store incoming request data before processing it in the event that your server doesn't have enough memory. Since you installed Nginx from source, you will need to create a directory that Nginx can use to store this data. Make a directory called body inside /var/lib/nginx:

      • sudo mkdir -p /var/lib/nginx/body

      With the startup script set up, you will now be able to start the Nginx server.

      Use the following command to start the server.

      • sudo systemctl start nginx

      To check that your server is active, run the following command:

      • sudo systemctl status nginx

      You will see the following output in your terminal stating that the server has started successfully:

      Output

      ● nginx.service - The NGINX HTTP and reverse proxy server Loaded: loaded (/lib/systemd/system/nginx.service; disabled; vendor preset: enabled) Active: active (running) since Mon 2018-11-05 13:59:40 UTC; 1s ago Process: 16199 ExecStart=/usr/sbin/nginx (code=exited, status=0/SUCCESS) Process: 16194 ExecStartPre=/usr/sbin/nginx -t (code=exited, status=0/SUCCESS) Main PID: 16201 (nginx) Tasks: 2 Memory: 1.3M CPU: 17ms CGroup: /system.slice/nginx.service ├─16201 nginx: master process /usr/sbin/ngin └─16202 nginx: worker proces . . .

      You now have a running Nginx server secured by NAXSI. The next step is to run a simulated XSS and SQL injection attack to ensure that NAXSI is protecting your server effectively.

      Step 4 — Testing NAXSI

      To test that Nginx is up and running with the NAXSI module enabled, you will try hitting the server with malicious HTTP requests and analyze the responses.

      First, copy the Public IP of your server and use the curl command to make malicious request the Nginx server.

      • curl 'http://your_server_ip/?q="><script>alert(0)</script>'

      This URL includes the XSS script "><script>alert(0)</script> in the q parameter and should be rejected by the server. According to the NAXSI rules that you set up earlier, you will be redirected to the error.html file and receive the following response:

      Output

      <html> <head> <title>Blocked By NAXSI</title> </head> <body> <div style="text-align: center"> <h1>Malicious Request</h1> <hr> <p>This Request Has Been Blocked By NAXSI.</p> </div> </body> </html>

      The NAXSI firewall has blocked the request.

      Now, verify the same using the Nginx log by tailing the Nginx server log using the following command:

      • tail -f /var/log/nginx/error.log

      In the log, you will see that the XSS request from the remote IP address is getting blocked by NAXSI:

      Output

      2018/11/07 17:05:05 [error] 21356#0: *1 NAXSI_FMT: ip=your_server_ip&server=your_server_ip&uri=/&learning=0&vers=0.56&total_processed=1&total_blocked=1&block=1&cscore0=$SQL&score0=8&cscore1=$XSS&score1=8&zone0=ARGS&id0=1001&var_name0=q, client: your_server_ip, server: localhost, request: "GET /?q="><script>alert(0)</script> HTTP/1.1", host: "your_server_ip"

      Press CTRL-C to exit tail and stop the output of the error log file.

      Next, try another URL request, this time with a malicious SQL Injection query.

      • curl 'http://your_server_ip/?q=1" or "1"="1"'

      The or "1"="1" part of the preceding URL can expose a user's data in a database, and will be blocked by NAXSI. It should produce the same response in the terminal:

      Output

      <html> <head> <title>Blocked By NAXSI</title> </head> <body> <div style="text-align: center"> <h1>Malicious Request</h1> <hr> <p>This Request Has Been Blocked By NAXSI.</p> </div> </body> </html>

      Now use tail to follow the server log again:

      • tail -f /var/log/nginx/error.log

      In the log file you'll see the blocked entry for the SQL Injection attempt:

      Output

      2018/11/07 17:08:01 [error] 21356#0: *2 NAXSI_FMT: ip=your_server_ip&server=your_server_ip&uri=/&learning=0&vers=0.56&total_processed=2&total_blocked=2&block=1&cscore0=$SQL&score0=40&cscore1=$XSS&score1=40&zone0=ARGS&id0=1001&var_name0=q, client: your_server_ip, server: localhost, request: "GET /?q=1" or "1"="1" HTTP/1.1", host: "your_server_ip"

      Press CTRL-C to exit the log.

      NAXSI has now successfully blocked an XSS and SQL injection attack, which proves that NAXSI has been configured correctly and that your Nginx web server is secure.

      Conclusion

      You now have a basic understanding of how to use NAXSI to protect your web server from malicious attacks. To learn more about setting up Nginx, see How To Set Up Nginx Server Blocks (Virtual Hosts) on Ubuntu 16.04. If you'd like to continue studying security on web servers, check out How To Secure Nginx with Let's Encrypt on Ubuntu 16.04 and How To Create a Self-Signed SSL Certificate for Nginx in Ubuntu 16.04.



      Source link

      How To Set Up Laravel, Nginx, and MySQL with Docker Compose


      The author selected The FreeBSD Foundation to receive a donation as part of the Write for DOnations program.

      Introduction

      Over the past few years, Docker has become a frequently used solution for deploying applications thanks to how it simplifies running and deploying applications in ephemeral containers. When using a LEMP application stack, for example, with PHP, Nginx, MySQL and the Laravel framework, Docker can significantly streamline the setup process.

      Docker Compose has further simplified the development process by allowing developers to define their infrastructure, including application services, networks, and volumes, in a single file. Docker Compose offers an efficient alternative to running multiple docker container create and docker container run commands.

      In this tutorial, you will build a web application using the Laravel framework, with Nginx as the web server and MySQL as the database, all inside Docker containers. You will define the entire stack configuration in a docker-compose file, along with configuration files for PHP, MySQL, and Nginx.

      Prerequisites

      Before you start, you will need:

      Step 1 — Downloading Laravel and Installing Dependencies

      As a first step, we will get the latest version of Laravel and install the dependencies for the project, including Composer, the application-level package manager for PHP. We will install these dependencies with Docker to avoid having to install Composer globally.

      First, check that you are in your home directory and clone the latest Laravel release to a directory called laravel-app:

      • cd ~
      • git clone https://github.com/laravel/laravel.git laravel-app

      Move into the laravel-app directory:

      Next, use Docker's composer image to mount the directories that you will need for your Laravel project and avoid the overhead of installing Composer globally:

      • docker run --rm -v $(pwd):/app composer install

      Using the -v and --rm flags with docker run creates an ephemeral container that will be bind-mounted to your current directory before being removed. This will copy the contents of your ~/laravel-app directory to the container and also ensure that the vendor folder Composer creates inside the container is copied to your current directory.

      As a final step, set permissions on the project directory so that it is owned by your non-root user:

      • sudo chown -R $USER:$USER ~/laravel-app

      This will be important when you write the Dockerfile for your application image in Step 4, as it will allow you to work with your application code and run processes in your container as a non-root user.

      With your application code in place, you can move on to defining your services with Docker Compose.

      Step 2 — Creating the Docker Compose File

      Building your applications with Docker Compose simplifies the process of setting up and versioning your infrastructure. To set up our Laravel application, we will write a docker-compose file that defines our web server, database, and application services.

      Open the file:

      • nano ~/laravel-app/docker-compose.yml

      In the docker-compose file, you will define three services: app, webserver, and db. Add the following code to the file, being sure to replace the root password for MYSQL_ROOT_PASSWORD, defined as an environment variable under the db service, with a strong password of your choice:

      ~/laravel-app/docker-compose.yml

      version: '3'
      services:
      
        #PHP Service
        app:
          build:
            context: .
            dockerfile: Dockerfile
          image: digitalocean.com/php
          container_name: app
          restart: unless-stopped
          tty: true
          environment:
            SERVICE_NAME: app
            SERVICE_TAGS: dev
          working_dir: /var/www
          networks:
            - app-network
      
        #Nginx Service
        webserver:
          image: nginx:alpine
          container_name: webserver
          restart: unless-stopped
          tty: true
          ports:
            - "80:80"
            - "443:443"
          networks:
            - app-network
      
        #MySQL Service
        db:
          image: mysql:5.7.22
          container_name: db
          restart: unless-stopped
          tty: true
          ports:
            - "3306:3306"
          environment:
            MYSQL_DATABASE: laravel
            MYSQL_ROOT_PASSWORD: your_mysql_root_password
            SERVICE_TAGS: dev
            SERVICE_NAME: mysql
          networks:
            - app-network
      
      #Docker Networks
      networks:
        app-network:
          driver: bridge
      

      The services defined here include:

      • app: This service definition contains the Laravel application and runs a custom Docker image, digitalocean.com/php, that you will define in Step 4. It also sets the working_dir in the container to /var/www.
      • webserver: This service definition pulls the nginx:alpine image from Docker and exposes ports 80 and 443.
      • db: This service definition pulls the mysql:5.7.22 image from Docker and defines a few environmental variables, including a database called laravel for your application and the root password for the database. You are free to name the database whatever you would like, and you should replace your_mysql_root_password with your own strong password. This service definition also maps port 3306 on the host to port 3306 on the container.

      Each container_name property defines a name for the container, which corresponds to the name of the service. If you don't define this property, Docker will assign a name to each container by combining a historically famous person's name and a random word separated by an underscore.

      To facilitate communication between containers, the services are connected to a bridge network called app-network. A bridge network uses a software bridge that allows containers connected to the same bridge network to communicate with each other. The bridge driver automatically installs rules in the host machine so that containers on different bridge networks cannot communicate directly with each other. This creates a greater level of security for applications, ensuring that only related services can communicate with one another. It also means that you can define multiple networks and services connecting to related functions: front-end application services can use a frontend network, for example, and back-end services can use a backend network.

      Let's look at how to add volumes and bind mounts to your service definitions to persist your application data.

      Step 3 — Persisting Data

      Docker has powerful and convenient features for persisting data. In our application, we will make use of volumes and bind mounts for persisting the database, and application and configuration files. Volumes offer flexibility for backups and persistence beyond a container's lifecycle, while bind mounts facilitate code changes during development, making changes to your host files or directories immediately available in your containers. Our setup will make use of both.

      Warning: By using bind mounts, you make it possible to change the host filesystem through processes running in a container, including creating, modifying, or deleting important system files or directories. This is a powerful ability with security implications, and could impact non-Docker processes on the host system. Use bind mounts with care.

      In the docker-compose file, define a volume called dbdata under the db service definition to persist the MySQL database:

      ~/laravel-app/docker-compose.yml

      ...
      #MySQL Service
      db:
        ...
          volumes:
            - dbdata:/var/lib/mysql
          networks:
            - app-network
        ...
      

      The named volume dbdata persists the contents of the /var/lib/mysql folder present inside the container. This allows you to stop and restart the db service without losing data.

      At the bottom of the file, add the definition for the dbdata volume:

      ~/laravel-app/docker-compose.yml

      ...
      #Volumes
      volumes:
        dbdata:
          driver: local
      

      With this definition in place, you will be able to use this volume across services.

      Next, add a bind mount to the db service for the MySQL configuration files you will create in Step 7:

      ~/laravel-app/docker-compose.yml

      ...
      #MySQL Service
      db:
        ...
          volumes:
            - dbdata:/var/lib/mysql
            - ./mysql/my.cnf:/etc/mysql/my.cnf
        ...
      

      This bind mount binds ~/laravel-app/mysql/my.cnf to /etc/mysql/my.cnf in the container.

      Next, add bind mounts to the webserver service. There will be two: one for your application code and another for the Nginx configuration definition that you will create in Step 6:

      ~/laravel-app/docker-compose.yml

      #Nginx Service
      webserver:
        ...
        volumes:
            - ./:/var/www
            - ./nginx/conf.d/:/etc/nginx/conf.d/
        networks:
            - app-network
      

      The first bind mount binds the application code in the ~/laravel-app directory to the /var/www directory inside the container. The configuration file that you will add to ~/laravel-app/nginx/conf.d/ will also be mounted to /etc/nginx/conf.d/ in the container, allowing you to add or modify the configuration directory's contents as needed.

      Finally, add the following bind mounts to the app service for the application code and configuration files:

      ~/laravel-app/docker-compose.yml

      #PHP Service
      app:
        ...
        volumes:
             - ./:/var/www
             - ./php/local.ini:/usr/local/etc/php/conf.d/local.ini
        networks:
            - app-network
      

      The app service is bind-mounting the ~/laravel-app folder, which contains the application code, to the /var/www folder in the container. This will speed up the development process, since any changes made to your local application directory will be instantly reflected inside the container. You are also binding your PHP configuration file, ~/laravel-app/php/local.ini, to /usr/local/etc/php/conf.d/local.ini inside the container. You will create the local PHP configuration file in Step 5.

      Your docker-compose file will now look like this:

      ~/laravel-app/docker-compose.yml

      version: '3'
      services:
      
        #PHP Service
        app:
          build:
            context: .
            dockerfile: Dockerfile
          image: digitalocean.com/php
          container_name: app
          restart: unless-stopped
          tty: true
          environment:
            SERVICE_NAME: app
            SERVICE_TAGS: dev
          working_dir: /var/www
          volumes:
            - ./:/var/www
            - ./php/local.ini:/usr/local/etc/php/conf.d/local.ini
          networks:
            - app-network
      
        #Nginx Service
        webserver:
          image: nginx:alpine
          container_name: webserver
          restart: unless-stopped
          tty: true
          ports:
            - "80:80"
            - "443:443"
          volumes:
            - ./:/var/www
            - ./nginx/conf.d/:/etc/nginx/conf.d/
          networks:
            - app-network
      
        #MySQL Service
        db:
          image: mysql:5.7.22
          container_name: db
          restart: unless-stopped
          tty: true
          ports:
            - "3306:3306"
          environment:
            MYSQL_DATABASE: laravel
            MYSQL_ROOT_PASSWORD: your_mysql_root_password
            SERVICE_TAGS: dev
            SERVICE_NAME: mysql
          volumes:
            - dbdata:/var/lib/mysql/
            - ./mysql/my.cnf:/etc/mysql/my.cnf
          networks:
            - app-network
      
      #Docker Networks
      networks:
        app-network:
          driver: bridge
      #Volumes
      volumes:
        dbdata:
          driver: local
      

      Save the file and exit your editor when you are finished making changes.

      With your docker-compose file written, you can now build the custom image for your application.

      Step 4 — Creating the Dockerfile

      Docker allows you to specify the environment inside of individual containers with a Dockerfile. A Dockerfile enables you to create custom images that you can use to install the software required by your application and configure settings based on your requirements. You can push the custom images you create to Docker Hub or any private registry.

      Our Dockerfile will be located in our ~/laravel-app directory. Create the file:

      • nano ~/laravel-app/Dockerfile

      This Dockerfile will set the base image and specify the necessary commands and instructions to build the Laravel application image. Add the following code to the file:

      ~/laravel-app/php/Dockerfile

      FROM php:7.2-fpm
      
      # Copy composer.lock and composer.json
      COPY composer.lock composer.json /var/www/
      
      # Set working directory
      WORKDIR /var/www
      
      # Install dependencies
      RUN apt-get update && apt-get install -y 
          build-essential 
          mysql-client 
          libpng-dev 
          libjpeg62-turbo-dev 
          libfreetype6-dev 
          locales 
          zip 
          jpegoptim optipng pngquant gifsicle 
          vim 
          unzip 
          git 
          curl
      
      # Clear cache
      RUN apt-get clean && rm -rf /var/lib/apt/lists/*
      
      # Install extensions
      RUN docker-php-ext-install pdo_mysql mbstring zip exif pcntl
      RUN docker-php-ext-configure gd --with-gd --with-freetype-dir=/usr/include/ --with-jpeg-dir=/usr/include/ --with-png-dir=/usr/include/
      RUN docker-php-ext-install gd
      
      # Install composer
      RUN curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer
      
      # Add user for laravel application
      RUN groupadd -g 1000 www
      RUN useradd -u 1000 -ms /bin/bash -g www www
      
      # Copy existing application directory contents
      COPY . /var/www
      
      # Copy existing application directory permissions
      COPY --chown=www:www . /var/www
      
      # Change current user to www
      USER www
      
      # Expose port 9000 and start php-fpm server
      EXPOSE 9000
      CMD ["php-fpm"]
      

      First, the Dockerfile creates an image on top of the php:7.2-fpm Docker image. This is a Debian-based image that has the PHP FastCGI implementation PHP-FPM installed. The file also installs the prerequisite packages for Laravel: mcrypt, pdo_mysql, mbstring, and imagick with composer.

      The RUN directive specifies the commands to update, install, and configure settings inside the container, including creating a dedicated user and group called www. The WORKDIR instruction specifies the /var/www directory as the working directory for the application.

      Creating a dedicated user and group with restricted permissions mitigates the inherent vulnerability when running Docker containers, which run by default as root. Instead of running this container as root, we've created the www user, who has read/write access to the /var/www folder thanks to the COPY instruction that we are using with the --chown flag to copy the application folder's permissions.

      Finally, the EXPOSE command exposes a port in the container, 9000, for the php-fpm server. CMD specifies the command that should run once the container is created. Here, CMD specifies "php-fpm", which will start the server.

      Save the file and exit your editor when you are finished making changes.

      You can now move on to defining your PHP configuration.

      Step 5 — Configuring PHP

      Now that you have defined your infrastructure in the docker-compose file, you can configure the PHP service to act as a PHP processor for incoming requests from Nginx.

      To configure PHP, you will create the local.ini file inside the php folder. This is the file that you bind-mounted to /usr/local/etc/php/conf.d/local.ini inside the container in Step 2. Creating this file will allow you to override the default php.ini file that PHP reads when it starts.

      Create the php directory:

      Next, open the local.ini file:

      • nano ~/laravel-app/php/local.ini

      To demonstrate how to configure PHP, we'll add the following code to set size limitations for uploaded files:

      ~/laravel-app/php/local.ini

      upload_max_filesize=40M
      post_max_size=40M
      

      The upload_max_filesize and post_max_size directives set the maximum allowed size for uploaded files, and demonstrate how you can set php.ini configurations from your local.ini file. You can put any PHP-specific configuration that you want to override in the local.ini file.

      Save the file and exit your editor.

      With your PHP local.ini file in place, you can move on to configuring Nginx.

      Step 6 — Configuring Nginx

      With the PHP service configured, you can modify the Nginx service to use PHP-FPM as the FastCGI server to serve dynamic content. The FastCGI server is based on a binary protocol for interfacing interactive programs with a web server. For more information, please refer to this article on Understanding and Implementing FastCGI Proxying in Nginx.

      To configure Nginx, you will create an app.conf file with the service configuration in the ~/laravel-app/nginx/conf.d/ folder.

      First, create the nginx/conf.d/ directory:

      • mkdir -p ~/laravel-app/nginx/conf.d

      Next, create the app.conf configuration file:

      • nano ~/laravel-app/nginx/conf.d/app.conf

      Add the following code to the file to specify your Nginx configuration:

      ~/laravel-app/nginx/conf.d/app.conf

      server {
          listen 80;
          index index.php index.html;
          error_log  /var/log/nginx/error.log;
          access_log /var/log/nginx/access.log;
          root /var/www/public;
          location ~ .php$ {
              try_files $uri =404;
              fastcgi_split_path_info ^(.+.php)(/.+)$;
              fastcgi_pass app:9000;
              fastcgi_index index.php;
              include fastcgi_params;
              fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
              fastcgi_param PATH_INFO $fastcgi_path_info;
          }
          location / {
              try_files $uri $uri/ /index.php?$query_string;
              gzip_static on;
          }
      }
      

      The server block defines the configuration for the Nginx web server with the following directives:

      • listen: This directive defines the port on which the server will listen to incoming requests.
      • error_log and access_log: These directives define the files for writing logs.
      • root: This directive sets the root folder path, forming the complete path to any requested file on the local file system.

      In the php location block, the fastcgi_pass directive specifies that the app service is listening on a TCP socket on port 9000. This makes the PHP-FPM server listen over the network rather than on a Unix socket. Though a Unix socket has a slight advantage in speed over a TCP socket, it does not have a network protocol and thus skips the network stack. For cases where hosts are located on one machine, a Unix socket may make sense, but in cases where you have services running on different hosts, a TCP socket offers the advantage of allowing you to connect to distributed services. Because our app container is running on a different host from our webserver container, a TCP socket makes the most sense for our configuration.

      Save the file and exit your editor when you are finished making changes.

      Thanks to the bind mount you created in Step 2, any changes you make inside the nginx/conf.d/ folder will be directly reflected inside the webserver container.

      Next, let's look at our MySQL settings.

      Step 7 — Configuring MySQL

      With PHP and Nginx configured, you can enable MySQL to act as the database for your application.

      To configure MySQL, you will create the my.cnf file in the mysql folder. This is the file that you bind-mounted to /etc/mysql/my.cnf inside the container in Step 2. This bind mount allows you to override the my.cnf settings as and when required.

      To demonstrate how this works, we'll add settings to the my.cnf file that enable the general query log and specify the log file.

      First, create the mysql directory:

      • mkdir ~/laravel-app/mysql

      Next, make the my.cnf file:

      • nano ~/laravel-app/mysql/my.cnf

      In the file, add the following code to enable the query log and set the log file location:

      ~/laravel-app/mysql/my.cnf

      [mysqld]
      general_log = 1
      general_log_file = /var/lib/mysql/general.log
      

      This my.cnf file enables logs, defining the general_log setting as 1 to allow general logs. The general_log_file setting specifies where the logs will be stored.

      Save the file and exit your editor.

      Our next step will be to start the containers.

      Step 8 — Running the Containers and Modifying Environment Settings

      Now that you have defined all of your services in your docker-compose file and created the configuration files for these services, you can start the containers. As a final step, though, we will make a copy of the .env.example file that Laravel includes by default and name the copy .env, which is the file Laravel expects to define its environment:

      We will configure the specific details of our setup in this file once we have started the containers.

      With all of your services defined in your docker-compose file, you just need to issue a single command to start all of the containers, create the volumes, and set up and connect the networks:

      When you run docker-compose up for the first time, it will download all of the necessary Docker images, which might take a while. Once the images are downloaded and stored in your local machine, Compose will create your containers. The -d flag daemonizes the process, running your containers in the background.

      Once the process is complete, use the following command to list all of the running containers:

      You will see the following output with details about your app, webserver, and db containers:

      Output

      CONTAINER ID NAMES IMAGE STATUS PORTS c31b7b3251e0 db mysql:5.7.22 Up 2 seconds 0.0.0.0:3306->3306/tcp ed5a69704580 app digitalocean.com/php Up 2 seconds 9000/tcp 5ce4ee31d7c0 webserver nginx:alpine Up 2 seconds 0.0.0.0:80->80/tcp, 0.0.0.0:443->443/tcp

      The CONTAINER ID in this output is a unique identifier for each container, while NAMES lists the service name associated with each. You can use both of these identifiers to access the containers. IMAGE defines the image name for each container, while STATUS provides information about the container's state: whether it's running, restarting, or stopped.

      You can now modify the .env file on the app container to include specific details about your setup.

      Open the file using docker-compose exec, which allows you to run specific commands in containers. In this case, you are opening the file for editing:

      • docker-compose exec app nano .env

      Find the block that specifies DB_CONNECTION and update it to reflect the specifics of your setup. You will modify the following fields:

      • DB_HOST will be your db database container.
      • DB_DATABASE will be the laravel database.
      • DB_USERNAME will be the username you will use for your database. In this case, we will use laraveluser.
      • DB_PASSWORD will be the secure password you would like to use for this user account.

      /var/www/.env

      DB_CONNECTION=mysql
      DB_HOST=db
      DB_PORT=3306
      DB_DATABASE=laravel
      DB_USERNAME=laraveluser
      DB_PASSWORD=your_laravel_db_password
      

      Save your changes and exit your editor.

      Next, set the application key for the Laravel application with the php artisan key:generate command. This command will generate a key and copy it to your .env file, ensuring that your user sessions and encrypted data remain secure:

      • docker-compose exec app php artisan key:generate

      You now have the environment settings required to run your application. To cache these settings into a file, which will boost your application's load speed, run:

      • docker-compose exec app php artisan config:cache

      Your configuration settings will be loaded into /var/www/bootstrap/cache/config.php on the container.

      As a final step, visit http://your_server_ip in the browser. You will see the following home page for your Laravel application:

      Laravel Home Page

      With your containers running and your configuration information in place, you can move on to configuring your user information for the laravel database on the db container.

      Step 9 — Creating a User for MySQL

      The default MySQL installation only creates the root administrative account, which has unlimited privileges on the database server. In general, it's better to avoid using the root administrative account when interacting with the database. Instead, let's create a dedicated database user for our application's Laravel database.

      To create a new user, execute an interactive bash shell on the db container with docker-compose exec:

      • docker-compose exec db bash

      Inside the container, log into the MySQL root administrative account:

      You will be prompted for the password you set for the MySQL root account during installation in your docker-compose file.

      Start by checking for the database called laravel, which you defined in your docker-compose file. Run the show databases command to check for existing databases:

      You will see the laravel database listed in the output:

      Output

      +--------------------+ | Database | +--------------------+ | information_schema | | laravel | | mysql | | performance_schema | | sys | +--------------------+ 5 rows in set (0.00 sec)

      Next, create the user account that will be allowed to access this database. Our username will be laraveluser, though you can replace this with another name if you'd prefer. Just be sure that your username and password here match the details you set in your .env file in the previous step:

      • GRANT ALL ON laravel.* TO 'laraveluser'@'%' IDENTIFIED BY 'your_laravel_db_password';

      Flush the privileges to notify the MySQL server of the changes:

      Exit MySQL:

      Finally, exit the container:

      You have configured the user account for your Laravel application database and are ready to migrate your data and work with the Tinker console.

      Step 10 — Migrating Data and Working with the Tinker Console

      With your application running, you can migrate your data and experiment with the tinker command, which will initiate a PsySH console with Laravel preloaded. PsySH is a runtime developer console and interactive debugger for PHP, and Tinker is a REPL specifically for Laravel. Using the tinker command will allow you to interact with your Laravel application from the command line in an interactive shell.

      First, test the connection to MySQL by running the Laravel artisan migrate command, which creates a migrations table in the database from inside the container:

      • docker-compose exec app php artisan migrate

      This command will migrate the default Laravel tables. The output confirming the migration will look like this:

      Output

      Migration table created successfully. Migrating: 2014_10_12_000000_create_users_table Migrated: 2014_10_12_000000_create_users_table Migrating: 2014_10_12_100000_create_password_resets_table Migrated: 2014_10_12_100000_create_password_resets_table

      Once the migration is complete, you can run a query to check if you are properly connected to the database using the tinker command:

      • docker-compose exec app php artisan tinker

      Test the MySQL connection by getting the data you just migrated:

      • DB::table('migrations')->get();

      You will see output that looks like this:

      Output

      => IlluminateSupportCollection {#2856 all: [ {#2862 +"id": 1, +"migration": "2014_10_12_000000_create_users_table", +"batch": 1, }, {#2865 +"id": 2, +"migration": "2014_10_12_100000_create_password_resets_table", +"batch": 1, }, ], }

      You can use tinker to interact with your databases and to experiment with services and models.

      With your Laravel application in place, you are ready for further development and experimentation.

      Conclusion

      You now have a LEMP stack application running on your server, which you've tested by accessing the Laravel welcome page and creating MySQL database migrations.

      Key to the simplicity of this installation is Docker Compose, which allows you to create a group of Docker containers, defined in a single file, with a single command. If you would like to learn more about how to do CI with Docker Compose, take a look at How To Configure a Continuous Integration Testing Environment with Docker and Docker Compose on Ubuntu 16.04. If you want to streamline your Laravel application deployment process then How to Automatically Deploy Laravel Applications with Deployer on Ubuntu 16.04 will be a relevant resource.



      Source link