One place for hosting & domains

      How To Secure a Containerized Node.js Application with Nginx, Let’s Encrypt, and Docker Compose


      Introduction

      There are multiple ways to enhance the flexibility and security of your Node.js application. Using a reverse proxy like Nginx offers you the ability to load balance requests, cache static content, and implement Transport Layer Security (TLS). Enabling encrypted HTTPS on your server ensures that communication to and from your application remains secure.

      Implementing a reverse proxy with TLS/SSL on containers involves a different set of procedures from working directly on a host operating system. For example, if you were obtaining certificates from Let’s Encrypt for an application running on a server, you would install the required software directly on your host. Containers allow you to take a different approach. Using Docker Compose, you can create containers for your application, your web server, and the Certbot client that will enable you to obtain your certificates. By following these steps, you can take advantage of the modularity and portability of a containerized workflow.

      In this tutorial, you will deploy a Node.js application with an Nginx reverse proxy using Docker Compose. You will obtain TLS/SSL certificates for the domain associated with your application and ensure that it receives a high security rating from SSL Labs. Finally, you will set up a cron job to renew your certificates so that your domain remains secure.

      Prerequisites

      To follow this tutorial, you will need:

      • An Ubuntu 18.04 server, a non-root user with sudo privileges, and an active firewall. For guidance on how to set these up, please see this Initial Server Setup guide.
      • Docker and Docker Compose installed on your server. For guidance on installing Docker, follow Steps 1 and 2 of How To Install and Use Docker on Ubuntu 18.04. For guidance on installing Compose, follow Step 1 of How To Install Docker Compose on Ubuntu 18.04.
      • A registered domain name. This tutorial will use example.com throughout. You can get one for free at Freenom, or use the domain registrar of your choice.
      • Both of the following DNS records set up for your server. You can follow this introduction to DigitalOcean DNS for details on how to add them to a DigitalOcean account, if that’s what you’re using:

        • An A record with example.com pointing to your server’s public IP address.
        • An A record with www.example.com pointing to your server’s public IP address.

      Step 1 — Cloning and Testing the Node Application

      As a first step, we will clone the repository with the Node application code, which includes the Dockerfile that we will use to build our application image with Compose. We can first test the application by building and running it with the docker run command, without a reverse proxy or SSL.

      In your non-root user’s home directory, clone the nodejs-image-demo repository from the DigitalOcean Community GitHub account. This repository includes the code from the setup described in How To Build a Node.js Application with Docker.

      Clone the repository into a directory called node_project:

      • git clone https://github.com/do-community/nodejs-image-demo.git node_project

      Change to the node_project directory:

      In this directory, there is a Dockerfile that contains instructions for building a Node application using the Docker node:10 image and the contents of your current project directory. You can look at the contents of the Dockerfile by typing:

      Output

      FROM node:10 RUN mkdir -p /home/node/app/node_modules && chown -R node:node /home/node/app WORKDIR /home/node/app COPY package*.json ./ RUN npm install COPY . . COPY --chown=node:node . . USER node EXPOSE 8080 CMD [ "node", "app.js" ]

      These instructions build a Node image by copying the project code from the current directory to the container and installing dependencies with npm install. They also take advantage of Docker's caching and image layering by separating the copy of package.json and package-lock.json, containing the project's listed dependencies, from the copy of the rest of the application code. Finally, the instructions specify that the container will be run as the non-root node user with the appropriate permissions set on the application code and node_modules directories.

      For more information about this Dockerfile and Node image best practices, please see the complete discussion in Step 3 of How To Build a Node.js Application with Docker.

      To test the application without SSL, you can build and tag the image using docker build and the -t flag. We will call the image node-demo, but you are free to name it something else:

      • docker build -t node-demo .

      Once the build process is complete, you can list your images with docker images:

      You will see the following output, confirming the application image build:

      Output

      REPOSITORY TAG IMAGE ID CREATED SIZE node-demo latest 23961524051d 7 seconds ago 896MB node 10 8a752d5af4ce 10 days ago 894MB

      Next, create the container with docker run. We will include three flags with this command:

      • -p: This publishes the port on the container and maps it to a port on our host. We will use port 80 on the host, but you should feel free to modify this as necessary if you have another process running on that port. For more information about how this works, see this discussion in the Docker docs on port binding.
      • -d: This runs the container in the background.
      • --name: This allows us to give the container a memorable name.

      Run the following command to build the container:

      • docker run --name node-demo -p 80:8080 -d node-demo

      Inspect your running containers with docker ps:

      You will see output confirming that your application container is running:

      Output

      CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 4133b72391da node-demo "node app.js" 17 seconds ago Up 16 seconds 0.0.0.0:80->8080/tcp node-demo

      You can now visit your domain to test your setup: http://example.com. Remember to replace example.com with your own domain name. Your application will display the following landing page:

      Application Landing Page

      Now that you have tested the application, you can stop the container and remove the images. Use docker ps again to get your CONTAINER ID:

      Output

      CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 4133b72391da node-demo "node app.js" 17 seconds ago Up 16 seconds 0.0.0.0:80->8080/tcp node-demo

      Stop the container with docker stop. Be sure to replace the CONTAINER ID listed here with your own application CONTAINER ID:

      You can now remove the stopped container and all of the images, including unused and dangling images, with docker system prune and the -a flag:

      Type y when prompted in the output to confirm that you would like to remove the stopped container and images. Be advised that this will also remove your build cache.

      With your application image tested, you can move on to building the rest of your setup with Docker Compose.

      Step 2 — Defining the Web Server Configuration

      With our application Dockerfile in place, we can create a configuration file to run our Nginx container. We will start with a minimal configuration that will include our domain name, document root, proxy information, and a location block to direct Certbot's requests to the .well-known directory, where it will place a temporary file to validate that the DNS for our domain resolves to our server.

      First, create a directory in the current project directory for the configuration file:

      Open the file with nano or your favorite editor:

      • nano nginx-conf/nginx.conf

      Add the following server block to proxy user requests to your Node application container and to direct Certbot's requests to the .well-known directory. Be sure to replace example.com with your own domain name:

      ~/node_project/nginx-conf/nginx.conf

      server {
              listen 80;
              listen [::]:80;
      
              root /var/www/html;
              index index.html index.htm index.nginx-debian.html;
      
              server_name example.com www.example.com;
      
              location / {
                      proxy_pass http://nodejs:8080;
              }
      
              location ~ /.well-known/acme-challenge {
                      allow all;
                      root /var/www/html;
              }
      }
      

      This server block will allow us to start the Nginx container as a reverse proxy, which will pass requests to our Node application container. It will also allow us to use Certbot's webroot plugin to obtain certificates for our domain. This plugin depends on the HTTP-01 validation method, which uses an HTTP request to prove that Certbot can access resources from a server that responds to a given domain name.

      Once you have finished editing, save and close the file. To learn more about Nginx server and location block algorithms, please refer to this article on Understanding Nginx Server and Location Block Selection Algorithms.

      With the web server configuration details in place, we can move on to creating our docker-compose.yml file, which will allow us to create our application services and the Certbot container we will use to obtain our certificates.

      Step 3 — Creating the Docker Compose File

      The docker-compose.yml file will define our services, including the Node application and web server. It will specify details like named volumes, which will be critical to sharing SSL credentials between containers, as well as network and port information. It will also allow us to specify specific commands to run when our containers are created. This file is the central resource that will define how our services will work together.

      Open the file in your current directory:

      First, define the application service:

      ~/node_project/docker-compose.yml

      version: '3'
      
      services:
        nodejs:
          build:
            context: .
            dockerfile: Dockerfile
          image: nodejs
          container_name: nodejs
          restart: unless-stopped
      

      The nodejs service definition includes the following:

      • build: This defines the configuration options, including the context and dockerfile, that will be applied when Compose builds the application image. If you wanted to use an existing image from a registry like Docker Hub, you could use the image instruction instead, with information about your username, repository, and image tag.
      • context: This defines the build context for the application image build. In this case, it's the current project directory.
      • dockerfile: This specifies the Dockerfile that Compose will use for the build — the Dockerfile you looked at in Step 1.
      • image, container_name: These apply names to the image and container.
      • restart: This defines the restart policy. The default is no, but we have set the container to restart unless it is stopped.

      Note that we are not including bind mounts with this service, since our setup is focused on deployment rather than development. For more information, please see the Docker documentation on bind mounts and volumes.

      To enable communication between the application and web server containers, we will also add a bridge network called app-network below the restart definition:

      ~/node_project/docker-compose.yml

      services:
        nodejs:
      ...
          networks:
            - app-network
      

      A user-defined bridge network like this enables communication between containers on the same Docker daemon host. This streamlines traffic and communication within your application, since it opens all ports between containers on the same bridge network, while exposing no ports to the outside world. Thus, you can be selective about opening only the ports you need to expose your frontend services.

      Next, define the webserver service:

      ~/node_project/docker-compose.yml

      ...
       webserver:
          image: nginx:latest
          container_name: webserver
          restart: unless-stopped
          ports:
            - "80:80"
          volumes:
            - web-root:/var/www/html
            - ./nginx-conf:/etc/nginx/conf.d
            - certbot-etc:/etc/letsencrypt
            - certbot-var:/var/lib/letsencrypt
          depends_on:
            - nodejs
          networks:
            - app-network
      

      Some of the settings we defined for the nodejs service remain the same, but we've also made the following changes:

      • image: This tells Compose to pull the latest Nginx image from Docker Hub.
      • ports: This exposes port 80 to enable the configuration options we've defined in our Nginx configuration.

      We have also specified the following named volumes and bind mounts:

      • web-root:/var/www/html: This will add our site's static assets, copied to a volume called web-root, to the the /var/www/html directory on the container.
      • ./nginx-conf:/etc/nginx/conf.d: This will bind mount the Nginx configuration directory on the host to the relevant directory on the container, ensuring that any changes we make to files on the host will be reflected in the container.
      • certbot-etc:/etc/letsencrypt: This will mount the relevant Let's Encrypt certificates and keys for our domain to the appropriate directory on the container.
      • certbot-var:/var/lib/letsencrypt: This mounts Let's Encrypt's default working directory to the appropriate directory on the container.

      Next, add the configuration options for the certbot container. Be sure to replace the domain and email information with your own domain name and contact email:

      ~/node_project/docker-compose.yml

      ...
        certbot:
          image: certbot/certbot
          container_name: certbot
          volumes:
            - certbot-etc:/etc/letsencrypt
            - certbot-var:/var/lib/letsencrypt
            - web-root:/var/www/html
          depends_on:
            - webserver
          command: certonly --webroot --webroot-path=/var/www/html --email sammy@example.com --agree-tos --no-eff-email --staging -d example.com  -d www.example.com 
      

      This definition tells Compose to pull the certbot/certbot image from Docker Hub. It also uses named volumes to share resources with the Nginx container, including the domain certificates and key in certbot-etc, the Let's Encrypt working directory in certbot-var, and the application code in web-root.

      Again, we've used depends_on to specify that the certbot container should be started once the webserver service is running.

      We've also included a command option that specifies the command to run when the container is started. It includes the certonly subcommand with the following options:

      • --webroot: This tells Certbot to use the webroot plugin to place files in the webroot folder for authentication.
      • --webroot-path: This specifies the path of the webroot directory.
      • --email: Your preferred email for registration and recovery.
      • --agree-tos: This specifies that you agree to ACME's Subscriber Agreement.
      • --no-eff-email: This tells Certbot that you do not wish to share your email with the Electronic Frontier Foundation (EFF). Feel free to omit this if you would prefer.
      • --staging: This tells Certbot that you would like to use Let's Encrypt's staging environment to obtain test certificates. Using this option allows you to test your configuration options and avoid possible domain request limits. For more information about these limits, please see Let's Encrypt's rate limits documentation.
      • -d: This allows you to specify domain names you would like to apply to your request. In this case, we've included example.com and www.example.com. Be sure to replace these with your own domain preferences.

      As a final step, add the volume and network definitions. Be sure to replace the username here with your own non-root user:

      ~/node_project/docker-compose.yml

      ...
      volumes:
        certbot-etc:
        certbot-var:
        web-root:
          driver: local
          driver_opts:
            type: none
            device: /home/sammy/node_project/views/
            o: bind
      
      networks:
        app-network:
          driver: bridge
      

      Our named volumes include our Certbot certificate and working directory volumes, and the volume for our site's static assets, web-root. In most cases, the default driver for Docker volumes is the local driver, which on Linux accepts options similar to the mount command. Thanks to this, we are able to specify a list of driver options with driver_opts that mount the views directory on the host, which contains our application's static assets, to the volume at runtime. The directory contents can then be shared between containers. For more information about the contents of the views directory, please see Step 2 of How To Build a Node.js Application with Docker.

      The docker-compose.yml file will look like this when finished:

      ~/node_project/docker-compose.yml

      version: '3'
      
      services:
        nodejs:
          build:
            context: .
            dockerfile: Dockerfile
          image: nodejs
          container_name: nodejs
          restart: unless-stopped
          networks:
            - app-network
      
        webserver:
          image: nginx:latest
          container_name: webserver
          restart: unless-stopped
          ports:
            - "80:80"
          volumes:
            - web-root:/var/www/html
            - ./nginx-conf:/etc/nginx/conf.d
            - certbot-etc:/etc/letsencrypt
            - certbot-var:/var/lib/letsencrypt
          depends_on:
            - nodejs
          networks:
            - app-network
      
        certbot:
          image: certbot/certbot
          container_name: certbot
          volumes:
            - certbot-etc:/etc/letsencrypt
            - certbot-var:/var/lib/letsencrypt
            - web-root:/var/www/html
          depends_on:
            - webserver
          command: certonly --webroot --webroot-path=/var/www/html --email sammy@example.com --agree-tos --no-eff-email --staging -d example.com  -d www.example.com 
      
      volumes:
        certbot-etc:
        certbot-var:
        web-root:
          driver: local
          driver_opts:
            type: none
            device: /home/sammy/node_project/views/
            o: bind
      
      networks:
        app-network:
          driver: bridge  
      

      With the service definitions in place, you are ready to start the containers and test your certificate requests.

      Step 4 — Obtaining SSL Certificates and Credentials

      We can start our containers with docker-compose up, which will create and run our containers and services in the order we have specified. If our domain requests are successful, we will see the correct exit status in our output and the right certificates mounted in the /etc/letsencrypt/live folder on the webserver container.

      Create the services with docker-compose up and the -d flag, which will run the nodejs and webserver containers in the background:

      You will see output confirming that your services have been created:

      Output

      Creating nodejs ... done Creating webserver ... done Creating certbot ... done

      Using docker-compose ps, check the status of your services:

      If everything was successful, your nodejs and webserver services should be Up and the certbot container will have exited with a 0 status message:

      Output

      Name Command State Ports ------------------------------------------------------------------------ certbot certbot certonly --webroot ... Exit 0 nodejs node app.js Up 8080/tcp webserver nginx -g daemon off; Up 0.0.0.0:80->80/tcp

      If you see anything other than Up in the State column for the nodejs and webserver services, or an exit status other than 0 for the certbot container, be sure to check the service logs with the docker-compose logs command:

      • docker-compose logs service_name

      You can now check that your credentials have been mounted to the webserver container with docker-compose exec:

      • docker-compose exec webserver ls -la /etc/letsencrypt/live

      If your request was successful, you will see output like this:

      Output

      total 16 drwx------ 3 root root 4096 Dec 23 16:48 . drwxr-xr-x 9 root root 4096 Dec 23 16:48 .. -rw-r--r-- 1 root root 740 Dec 23 16:48 README drwxr-xr-x 2 root root 4096 Dec 23 16:48 example.com

      Now that you know your request will be successful, you can edit the certbot service definition to remove the --staging flag.

      Open docker-compose.yml:

      Find the section of the file with the certbot service definition, and replace the --staging flag in the command option with the --force-renewal flag, which will tell Certbot that you want to request a new certificate with the same domains as an existing certificate. The certbot service definition should now look like this:

      ~/node_project/docker-compose.yml

      ...
        certbot:
          image: certbot/certbot
          container_name: certbot
          volumes:
            - certbot-etc:/etc/letsencrypt
            - certbot-var:/var/lib/letsencrypt
            - web-root:/var/www/html
          depends_on:
            - webserver
          command: certonly --webroot --webroot-path=/var/www/html --email sammy@example.com --agree-tos --no-eff-email --force-renewal -d example.com -d www.example.com
      ...
      

      You can now run docker-compose up to recreate the certbot container and its relevant volumes. We will also include the --no-deps option to tell Compose that it can skip starting the webserver service, since it is already running:

      • docker-compose up --force-recreate --no-deps certbot

      You will see output indicating that your certificate request was successful:

      Output

      certbot | IMPORTANT NOTES: certbot | - Congratulations! Your certificate and chain have been saved at: certbot | /etc/letsencrypt/live/example.com/fullchain.pem certbot | Your key file has been saved at: certbot | /etc/letsencrypt/live/example.com/privkey.pem certbot | Your cert will expire on 2019-03-26. To obtain a new or tweaked certbot | version of this certificate in the future, simply run certbot certbot | again. To non-interactively renew *all* of your certificates, run certbot | "certbot renew" certbot | - Your account credentials have been saved in your Certbot certbot | configuration directory at /etc/letsencrypt. You should make a certbot | secure backup of this folder now. This configuration directory will certbot | also contain certificates and private keys obtained by Certbot so certbot | making regular backups of this folder is ideal. certbot | - If you like Certbot, please consider supporting our work by: certbot | certbot | Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate certbot | Donating to EFF: https://eff.org/donate-le certbot | certbot exited with code 0

      With your certificates in place, you can move on to modifying your Nginx configuration to include SSL.

      Step 5 — Modifying the Web Server Configuration and Service Definition

      Enabling SSL in our Nginx configuration will involve adding an HTTP redirect to HTTPS and specifying our SSL certificate and key locations. It will also involve specifying our Diffie-Hellman group, which we will use for Perfect Forward Secrecy.

      Since you are going to recreate the webserver service to include these additions, you can stop it now:

      • docker-compose stop webserver

      Next, create a directory in your current project directory for your Diffie-Hellman key:

      Generate your key with the openssl command:

      • sudo openssl dhparam -out /home/sammy/node_project/dhparam/dhparam-2048.pem 2048

      It will take a few moments to generate the key.

      To add the relevant Diffie-Hellman and SSL information to your Nginx configuration, first remove the Nginx configuration file you created earlier:

      Open another version of the file:

      • nano nginx-conf/nginx.conf

      Add the following code to the file to redirect HTTP to HTTPS and to add SSL credentials, protocols, and security headers. Remember to replace example.com with your own domain:

      ~/node_project/nginx-conf/nginx.conf

      
      server {
              listen 80;
              listen [::]:80;
              server_name example.com www.example.com;
      
              location ~ /.well-known/acme-challenge {
                allow all;
                root /var/www/html;
              }
      
              location / {
                      rewrite ^ https://$host$request_uri? permanent;
              }
      }
      
      server {
              listen 443 ssl http2;
              listen [::]:443 ssl http2;
              server_name example.com www.example.com;
      
              server_tokens off;
      
              ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
              ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
      
              ssl_buffer_size 8k;
      
              ssl_dhparam /etc/ssl/certs/dhparam-2048.pem;
      
              ssl_protocols TLSv1.2 TLSv1.1 TLSv1;
              ssl_prefer_server_ciphers on;
      
              ssl_ciphers ECDH+AESGCM:ECDH+AES256:ECDH+AES128:DH+3DES:!ADH:!AECDH:!MD5;
      
              ssl_ecdh_curve secp384r1;
              ssl_session_tickets off;
      
              ssl_stapling on;
              ssl_stapling_verify on;
              resolver 8.8.8.8;
      
              location / {
                      try_files $uri @nodejs;
              }
      
              location @nodejs {
                      proxy_pass http://nodejs:8080;
                      add_header X-Frame-Options "SAMEORIGIN" always;
                      add_header X-XSS-Protection "1; mode=block" always;
                      add_header X-Content-Type-Options "nosniff" always;
                      add_header Referrer-Policy "no-referrer-when-downgrade" always;
                      add_header Content-Security-Policy "default-src * data: 'unsafe-eval' 'unsafe-inline'" always;
                      # add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
                      # enable strict transport security only if you understand the implications
              }
      
              root /var/www/html;
              index index.html index.htm index.nginx-debian.html;
      }
      

      The HTTP server block specifies the webroot for Certbot renewal requests to the .well-known/acme-challenge directory. It also includes a rewrite directive that directs HTTP requests to the root directory to HTTPS.

      The HTTPS server block enables ssl and http2. To read more about how HTTP/2 iterates on HTTP protocols and the benefits it can have for website performance, please see the introduction to How To Set Up Nginx with HTTP/2 Support on Ubuntu 18.04. This block also includes a series of options to ensure that you are using the most up-to-date SSL protocols and ciphers and that OSCP stapling is turned on. OSCP stapling allows you to offer a time-stamped response from your certificate authority during the initial TLS handshake, which can speed up the authentication process.

      The block also specifies your SSL and Diffie-Hellman credentials and key locations.

      Finally, we've moved the proxy pass information to this block, including a location block with a try_files directive, pointing requests to our aliased Node.js application container, and a location block for that alias, which includes security headers that will enable us to get A ratings on things like the SSL Labs and Security Headers server test sites. These headers include X-Frame-Options, X-Content-Type-Options, Referrer Policy, Content-Security-Policy, and X-XSS-Protection. The HTTP Strict Transport Security (HSTS) header is commented out — enable this only if you understand the implications and have assessed its "preload" functionality.

      Once you have finished editing, save and close the file.

      Before recreating the webserver service, you will need to add a few things to the service definition in your docker-compose.yml file, including relevant port information for HTTPS and a Diffie-Hellman volume definition.

      Open the file:

      In the webserver service definition, add the following port mapping and the dhparam named volume:

      ~/node_project/docker-compose.yml

      ...
       webserver:
          image: nginx:latest
          container_name: webserver
          restart: unless-stopped
          ports:
            - "80:80"
            - "443:443"
          volumes:
            - web-root:/var/www/html
            - ./nginx-conf:/etc/nginx/conf.d
            - certbot-etc:/etc/letsencrypt
            - certbot-var:/var/lib/letsencrypt
            - dhparam:/etc/ssl/certs
          depends_on:
            - nodejs
          networks:
            - app-network
      

      Next, add the dhparam volume to your volumes definitions:

      ~/node_project/docker-compose.yml

      ...
      volumes:
        ...
        dhparam:
          driver: local
          driver_opts:
            type: none
            device: /home/sammy/node_project/dhparam/
            o: bind
      

      Similarly to the web-root volume, the dhparam volume will mount the Diffie-Hellman key stored on the host to the webserver container.

      Save and close the file when you are finished editing.

      Recreate the webserver service:

      • docker-compose up -d --force-recreate --no-deps webserver

      Check your services with docker-compose ps:

      You should see output indicating that your nodejs and webserver services are running:

      Output

      Name Command State Ports ---------------------------------------------------------------------------------------------- certbot certbot certonly --webroot ... Exit 0 nodejs node app.js Up 8080/tcp webserver nginx -g daemon off; Up 0.0.0.0:443->443/tcp, 0.0.0.0:80->80/tcp

      Finally, you can visit your domain to ensure that everything is working as expected. Navigate your browser to https://example.com, making sure to substitute example.com with your own domain name. You will see the following landing page:

      Application Landing Page

      You should also see the lock icon in your browser's security indicator. If you would like, you can navigate to the SSL Labs Server Test landing page or the Security Headers server test landing page. The configuration options we've included should earn your site an A rating on both.

      Step 6 — Renewing Certificates

      Let's Encrypt certificates are valid for 90 days, so you will want to set up an automated renewal process to ensure that they do not lapse. One way to do this is to create a job with the cron scheduling utility. In this case, we will schedule a cron job using a script that will renew our certificates and reload our Nginx configuration.

      Open a script called ssl_renew.sh in your project directory:

      Add the following code to the script to renew your certificates and reload your web server configuration:

      ~/node_project/ssl_renew.sh

      #!/bin/bash
      
      /usr/local/bin/docker-compose -f /home/sammy/node_project/docker-compose.yml run certbot renew --dry-run 
      && /usr/local/bin/docker-compose -f /home/sammy/node_project/docker-compose.yml kill -s SIGHUP webserver
      

      In addition to specifying the location of our docker-compose binary, we also specify the location of our docker-compose.yml file in order to run docker-compose commands. In this case, we are using docker-compose run to start a certbot container and to override the command provided in our service definition with another: the renew subcommand, which will renew certificates that are close to expiring. We've included the --dry-run option here to test our script.

      The script then uses docker-compose kill to send a SIGHUP signal to the webserver container to reload the Nginx configuration. For more information on using this process to reload your Nginx configuration, please see this Docker blog post on deploying the official Nginx image with Docker.

      Close the file when you are finished editing. Make it executable:

      Next, open your root crontab file to run the renewal script at a specified interval:

      If this is your first time editing this file, you will be asked to choose an editor:

      crontab

      no crontab for root - using an empty one
      Select an editor.  To change later, run 'select-editor'.
        1. /bin/ed
        2. /bin/nano        <---- easiest
        3. /usr/bin/vim.basic
        4. /usr/bin/vim.tiny
      Choose 1-4 [2]: 
      ...
      

      At the bottom of the file, add the following line:

      crontab

      ...
      */5 * * * * /home/sammy/node_project/ssl_renew.sh >> /var/log/cron.log 2>&1
      

      This will set the job interval to every five minutes, so you can test whether or not your renewal request has worked as intended. We have also created a log file, cron.log, to record relevant output from the job.

      After five minutes, check cron.log to see whether or not the renewal request has succeeded:

      • tail -f /var/log/cron.log

      You should see output confirming a successful renewal:

      Output

      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ** DRY RUN: simulating 'certbot renew' close to cert expiry ** (The test certificates below have not been saved.) Congratulations, all renewals succeeded. The following certs have been renewed: /etc/letsencrypt/live/example.com/fullchain.pem (success) ** DRY RUN: simulating 'certbot renew' close to cert expiry ** (The test certificates above have not been saved.) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Killing webserver ... done

      You can now modify the crontab file to set a daily interval. To run the script every day at noon, for example, you would modify the last line of the file to look like this:

      crontab

      ...
      0 12 * * * /home/sammy/node_project/ssl_renew.sh >> /var/log/cron.log 2>&1
      

      You will also want to remove the --dry-run option from your ssl_renew.sh script:

      ~/node_project/ssl_renew.sh

      #!/bin/bash
      
      /usr/local/bin/docker-compose -f /home/sammy/node_project/docker-compose.yml run certbot renew 
      && /usr/local/bin/docker-compose -f /home/sammy/node_project/docker-compose.yml kill -s SIGHUP webserver
      

      Your cron job will ensure that your Let's Encrypt certificates don't lapse by renewing them when they are eligible.

      Conclusion

      You have used containers to set up and run a Node application with an Nginx reverse proxy. You have also secured SSL certificates for your application's domain and set up a cron job to renew these certificates when necessary.

      If you are interested in learning more about Let's Encrypt plugins, please see our articles on using the Nginx plugin or the standalone plugin.

      You can also learn more about Docker Compose by looking at the following resources:

      The Compose documentation is also a great resource for learning more about multi-container applications.



      Source link

      Let’s Take a Look at SEO Trends: How to Rank Higher in 2019


      Search Engine Optimization (SEO) is a vital part of any website owner or digital marketer’s work. This is unlikely to change in the new year, but that doesn’t mean you can just rely on old strategies. In fact, as browsing habits change, you’ll need to keep your SEO techniques up to date.

      The way people use search engines such as Google changes constantly. For example, over the past few years, ‘mobile-first’ has become an important mantra for improving both accessibility and page rankings. While nobody can tell for sure what the future holds, it is possible to get a good idea of what you should focus on for the next year.

      In this article, we’ll talk about why SEO will continue to be a critical consideration in the upcoming year. We’ll also discuss some of the trends that may come to dominate your SEO strategy in 2019. Let’s get started!

      The Current State of Search Engine Optimization (SEO)

      In case you’re new to the concept, Search Engine Optimization (SEO) refers to a series of techniques for helping your site rank higher in search results. It’s an integral aspect of everyday work for most developers and content creators, and looks poised to remain so for years to come.

      There is no shortage of ways you can improve SEO on your website. General considerations include making sure its loading times are kept to a minimum, for example, and performing keyword research to tailor your posts to match what people are searching for.

      However, while it might seem like SEO practices are evergreen, this is far from the case. In reality, what ranks well depends on the search engines’ algorithms, which are continually changing. This naturally means you can’t keep relying on the same optimization techniques over time and expect good results.

      As such, you’ll want to stay up-to-date with the changing world of SEO. This will help you keep your site optimized well into 2019 (and beyond).

      SEO Trends: 10 Tips for Ranking Higher in 2019

      To help you get a head-start on optimizing your content in the new year, we’re now going to take a look at some of the SEO trends that will be worth paying attention to in 2019. We’ll also give you some tips on how to adapt your content and strategy to take advantage of those trends. Let’s jump right in!

      1. Prepare Your Site for Voice Search

      Voice search has already nestled comfortably into many people’s lives. Perhaps you use Apple’s Siri, Amazon’s Echo, or Google’s Assistant, just to name three examples. As this technology becomes more prevalent so to will the need to consider how voice search will affect your SEO efforts.

      The main difference between typical SEO strategies and optimizing for voice search involves using more ‘natural’ phrasing. After all, text searches usually involve stilted, compressed phrases like “best blog hosting 2018.” However, if you were to use your voice to search for the same information, you’d probably say something like: “What is the best hosting for blogs this year?”

      Do you notice how the second phrase is both more natural and considerably longer? This means you’ll also want to consider optimizing your content for long-tail keywords to a greater degree. Since the ultimate goal is to use keywords people are likely to search for, this might actually make your job easier, as you won’t need to jam cumbersome key phrases into your content.

      2. Optimize Your Site for Speed

      Optimizing your site for performance is something we’ve discussed in several previous posts. However, the importance of this step bears repeating. Loading times will undoubtedly remain a huge consideration in 2019, especially when it comes to improving your site’s rankings.

      This issue became even more pressing in 2018, as Google announced it would begin factoring in page speed for mobile devices. This is due to the growing popularity of mobile browsing, and means that keeping load times short is now a primary concern for all website owners.

      Fortunately, we’ve also previously explored how to speed up your site in general. Key strategies include implementing a caching solution, as well as optimizing your media files. For more information, you can take a look at our full series of tutorials on performance optimization.

      3. Make Use of Artificial Intelligence (AI)

      The term Artificial Intelligence (AI) has a distinctly futuristic ring to it. So it’s no surprise that it’s going to play a major role in how SEO changes in the near future. We’re (unfortunately) not talking about hiring a robot to handle your SEO strategy, but that’s not as far from the reality as you might expect.

      Google already uses AI extensively, thanks to its RankBrain system. This is a bot that uses machine learning to continuously improve Google’s search results. It finds patterns and context in millions of pages, which the search engine can then use to return more relevant results for specific queries.

      However, Google isn’t the only party that can also use AI to its advantage. In fact, tools that utilize machine learning to improve your SEO are becoming more popular. One such example is Automated Insights.

      The Automated Insights home page.

      This solution helps you turn unorganized data, such as site analytics, into a clear narrative. In turn, that can help you spot patterns more quickly and start making improvements.

      Another tool that can help you when creating content is WordLift.

      The WordLift plugin.

      This WordPress plugin uses machine learning to help you optimize your content. It does that by both offering suggestions for the actual content and by adding structured metadata and suggesting relevant links.

      We suspect that this is only scratching the surface of what AI-based tools will be able to do in the future. As such, getting familiar with this technology now can give you a vital head start.

      4. Improve Your Mobile Pages

      Google’s mobile-first index means that the search engine now ranks pages based on their versions designed for mobile devices. As such, even if your site performs flawlessly on a desktop, but it’s hard to use and sluggish when viewed on a smartphone, your SEO rankings will likely suffer.

      For this reason, optimizing your site for mobiles is no longer optional. In reality, you’ll need to spend even more time making sure your mobile site is fast and usable. This is also called making your site responsive, since the goal is for it to work well regardless of the screen size or device type used to view it.

      You’ll also need to consider how your site will actually work on different screens. For example, if you’ve designed your navigation for desktop browsing, is it still as intuitive and simple to use on mobile devices? If your site contains additional elements, such as pop-ups, you’ll also need to ensure that they don’t interfere with the mobile user experience.

      Thankfully, this is not as difficult as it might seem. For instance, the vast majority of WordPress themes and plugins are built with responsive design in mind. However, to avoid any issues, you should still make sure to thoroughly test your site on multiple devices.

      5. Focus on More Personalized Results

      It often seems like people are getting less patient by the day. They want to find the information they need much more quickly, for instance, which is why Google has placed a greater focus on personalized results.

      Most notably, Google actually gathers information about each individual user to return the most relevant results. Another example can be found in Google’s ‘answer boxes.’

      A Google result using an answer box.

      Google’s service is also personalized by offering searchers contextual results based on previous searches or even the user’s location. If you try searching for “Where is the nearest coffee shop?”, you’ll be shown options that are close by.

      This may seem like a difficult trend to leverage to your own advantage, but it’s far from impossible. You can actually increase your odds of appearing in answer boxes by merely providing clear and organized information on your site. Using lists and distinct headings to summarize each page’s contents will also help Google parse and index the information, making it easier to get your site featured in the coveted ‘position 0.’

      6. Extend Your SEO Strategy to Your Social Media Channels

      Having a strong social media presence is a significant aspect of online marketing. Naturally, this also applies to your SEO strategy. While social media shares aren’t currently a direct ranking factor, there does seem to be a correlation between social signals and rankings.

      How this works is complicated, to say the least, and we won’t get too deep into the details here. Suffice it to say that the more your content is shared, the more traffic your site will likely get through search engines. This also helps you build backlinks and brand awareness, since more people will see and talk about your site.

      As such, it’s vital that you factor in your social media presence when considering SEO. Focus on a few essential platforms and maintain a consistent strategy for sharing content and interacting with your followers. This will help you across all areas of your marketing.

      7. Shift Your Focus Away from Google

      So far, we’ve consistently referred almost exclusively to Google when considering SEO. This is no accident, considering that it remains the most popular search engine by far. Still, it may not be a good idea to focus solely on Google’s ranking algorithms when putting together your SEO strategy.

      Amazon’s search engine, for example, is becoming one of the most significant on the web. As it turns out, over half of shoppers turn to Amazon when searching for products, rather than to Google. Another example comes in the form of YouTube, which remains the world’s second largest search engine.

      What this means for you is that relying solely on Google may not be feasible from now on. For example, if you want your products to be more visible, you’ll need to consider Amazon to a much larger degree. If you have a lot a video and other non-text content, on the other hand, YouTube and similar platforms should be high on your list of targets.

      8. Understand How Blockchain Affects SEO

      If you’ve never heard of ‘blockchain’ before, you’re not alone. While the concept is too complex to do full justice here, we can break it down in simplified terms. In essence, a blockchain is a list of records that cannot be modified after the fact. Every item – or block – in the chain is recorded and preserved as-is forever.

      This technology can affect SEO, because using blockchain changes the relationship between advertisers and website owners. With blockchains, you can guarantee that every click is valid, meaning that the days of bot visitors are over. This will lead to improved verified data, meaning that sites won’t be able to get away with artificially improving their rankings using automated clicks.

      At this point, your best move is simply to learn more about blockchain and how it can affect your site and business. This is a complex and nuanced topic, so being prepared is key. You may even wish to hire an expert to help you if you’re interested in implementing blockchain yourself.

      9. Improve Your Technical SEO

      SEO is often thought of as a concern exclusive to content creators and marketers. However, the reality is that it’s also something developers need to think about. The process of ‘technical SEO’ refers to making sure your site is compatible with the standards set by search engines.

      Two major aspects of technical SEO that we’ve already touched on include page speed and mobile-friendliness. However, another crucial consideration is site security. For instance, Google now requires sites to be delivered using HTTPS, in order to be labeled as ‘secure’ in the Chrome browser.

      These are just a few of the elements that fall under the technical SEO umbrella. While we don’t have time to go through everything, here are a few additional aspects you’ll want to consider:

      • Site architecture. By designing your site in a logical way, you’ll make it easier for crawlers to catalog and index your pages, which improves your rankings.
      • Rich snippets. This is a type of markup that adds extra information to your pages, making them stand out more in search results.
      • Duplicate content. Search engines penalize sites that feature the same content in more than one location. As such, you’ll want to ensure that you don’t repeat or re-use the same text.

      As we mentioned, this is by no means a comprehensive list. However, it should be enough to get you started, whether or not you have an interest in development.

      10. Use SEO to Optimize Your Videos

      For our final tip, we should acknowledge that SEO isn’t just about text. It’s also vital to look at SEO as it pertains to video content. This is increasingly important as video is becoming more prevalent by the day.

      To give you an example, in 2018 nearly half of all internet users watched at least an hour of online video every week. Site owners have started to take heed of this trend, and you can do the same. An easy way to start? Include videos on your site. Search engines consider the quality of your content and the length of time users stick around as ranking factors. By using video, you can improve both metrics.

      What’s more, you can also aim to improve SEO on the videos themselves. This involves using clear and descriptive titles, choosing the right video hosting platform, and making sure to address your users’ questions and pain points. This will make sure your visitors get the information they need while improving your rankings at the same time.

      Moving on Up

      Search Engine Optimization (SEO) is not a static pursuit. As the internet changes, so do the parameters that determine how well your site ranks in search engines. This means that you need to stay up-to-speed with the latest SEO trends in order to ensure continued success for years to come.

      What do you think SEO will look like in 2019 and beyond? Share your predictions in the DreamHost Community and let’s discuss!



      Source link

      Как повысить безопасность Nginx с помощью Let’s Encrypt в Ubuntu 18.04


      Предыдущая версия руководства была написана Хэйзел Вирдо.

      Введение

      Let’s Encrypt представляет собой центр сертификации (Certificate Authority, CA), позволяющий получать и устанавливать бесплатные сертификаты TLS/SSL, тем самым позволяя использовать шифрованный HTTPS на веб-серверах. Процесс получения сертификатов упрощается за счёт наличия клиента Certbot, который пытается автоматизировать большую часть (если не все) необходимых операций. В настоящее время весь процесс получения и установки сертификатов полностью автоматизирован и для Apache и для Nginx.

      В этом руководстве мы используем Certbot для получения бесплатного SSL сертификата для Nginx на Ubuntu 18.04, а также настроим автоматическое продление этого сертификата.

      Перед установкой

      Перед тем, как начать следовать описанным в этой статье шагам, убедитесь, что у вас есть:

      • Сервер с Ubuntu 18.04, настроенный согласно руководству по первичной настройке сервера с Ubuntu 18.04, включая настройку не-рутового (non-root) пользователя с привилегиями sudo и настройку файрвола.
      • Зарегистрированное доменное имя. В этом руководстве мы будем использовать example.com. Вы можете приобрести доменное имя на Namecheap, получить бесплатное доменное имя на Freenom или использовать любой другой регистратор доменных имён.
      • Для вашего сервера настроены обе записи DNS, указанные ниже. Для их настройки вы можете использовать наше введение в работу с DNS в DigitalOcean.
        • Запись A для example.com, указывающая на публичный IP адрес вашего сервера.
        • Запись A для www.example.com, указывающая на публичный IP адрес вашего сервера.
      • Nginx, установленный согласно инструкциям из руководства Как установить Nginx в Ubuntu 18.04. Убедитесь, что у вас есть настроенный серверный блок для вашего домена. В этом руководстве мы будем использовать /etc/nginx/sites-available/example.com в качестве примера.

      Шаг 1 – Установка Certbot

      Перед началом использования Let’s Encrypt для получения SSL сертификаты установим Certbot на ваш сервер.

      Certbot находится в активной разработке, поэтому пакеты Certbot, предоставляемые Ubuntu, обычно являются устаревшими. Тем не менее, разработчики Certbot поддерживают свой репозиторий пакетов для Ubuntu с актуальными версиями, поэтому мы будем использовать именно этот репозиторий.

      Сначала добавим репозиторий:

      • sudo add-apt-repository ppa:certbot/certbot

      Далее нажмите ENTER.

      Установим пакет Certbot для Nginx с помощью apt:

      • sudo apt install python-certbot-nginx

      Теперь Certbot готов к использованию, но для того, чтобы он мог настроить SSL для Nginx, нам сперва необходимо проверить кое-какие настройки Nginx.

      Шаг 2 – Проверка настроек Nginx

      Certbot должен иметь возможность найти корректный серверный блок в вашей конфигурации Nginx для того, чтобы автоматически конфигурировать SSL. Для этого он будет искать директиву server_name, которая совпадает с доменным именем, для которого вы запросите сертификат.

      Если вы следовали инструкциям по настройке серверного блока в руководстве по установке Nginx, у вас должен быть серверный блок для вашего домена по адресу /etc/nginx/sites-available/example.com с уже правильно настроенной директивой server_name.

      Для проверки откройте файл серверного блока в nano или любом другом текстовом редакторе:

      • sudo nano /etc/nginx/sites-available/example.com

      Найдите строку с server_name. Она должна выглядеть примерно так:

      /etc/nginx/sites-available/example.com

      ...
      server_name example.com www.example.com;
      ...
      

      Если она выглядит таким образом, закройте файл и переходите к следующему шагу.

      Если она не выглядит так, как описано выше, обновите директиву server_name. Затем сохраните и закройте файл, после чего проверьте корректность синтаксиса вашего конфигурационного файла командой:

      Если вы получили ошибку, откройте файл серверного блока и проверьте его на наличие опечаток или пропущенных символов. После того, как ваш конфигурационный файл будет проходить проверку на корректность, перезагрузите Nginx для применения новой конфигурации:

      • sudo systemctl reload nginx

      Теперь Certbot может находить и обновлять корректный серверный блок.

      Далее обновим настройки файрвола для пропуска HTTPS трафика.

      Шаг 3 - Разрешение HTTPS в файрволе

      Если у вас включен файрвол ufw, как рекомендуется в руководстве по первичной настройке сервера, вам необходимо внести некоторые изменения в его настройки для разрешения трафика HTTPS. К счастью, Nginx регистрирует необходимые профили в ufw в момент установки.

      Вы можете ознакомиться с текущими настройками командой:

      Скорее всего вывод будет выглядеть следующим образом:

      Вывод

      Status: active To Action From -- ------ ---- OpenSSH ALLOW Anywhere Nginx HTTP ALLOW Anywhere OpenSSH (v6) ALLOW Anywhere (v6) Nginx HTTP (v6) ALLOW Anywhere (v6)

      Как видно из вывода, разрешён только трафик HTTP.

      Для того, чтобы разрешить трафик HTTPS, разрешим профиль Nginx Full и удалим избыточный профиль Nginx HTTP:

      • sudo ufw allow 'Nginx Full'
      • sudo ufw delete allow 'Nginx HTTP'

      Проверим внесённые изменения:

      Теперь настройки ufw должны выглядеть следующим образом:

      Вывод

      Status: active To Action From -- ------ ---- OpenSSH ALLOW Anywhere Nginx Full ALLOW Anywhere OpenSSH (v6) ALLOW Anywhere (v6) Nginx Full (v6) ALLOW Anywhere (v6)

      Теперь мы можем запустить Certbot и получить наши сертификаты.

      Шаг 4 - Получение SSL сертификата

      Certbot предоставляет несколько способов получения сертификатов SSL с использованием плагинов. Плагин для Nginx берёт на себя настройку Nginx и перезагрузку конфигурации, когда это необходимо. Для использования плагина выполним команду:

      • sudo certbot --nginx -d example.com -d www.example.com

      Эта команда запускает certbot с плагином --nginx, ключи -d определяют имена доменов, для которых должен быть выпущен сертификат.

      Если это первый раз, когда вы запускаете certbot, вам будет предложено ввести адрес электронной почты и согласиться с условиями использования сервиса. После этого certbot свяжется с сервером Let's Encrypt, а затем проверит, что вы действительно контролируете домен, для которого вы запросили сертификат.

      Если всё прошло успешно, certbot спросит, как вы хотите настроить конфигурацию HTTPS.

      Вывод

      Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP access. ------------------------------------------------------------------------------- 1: No redirect - Make no further changes to the webserver configuration. 2: Redirect - Make all requests redirect to secure HTTPS access. Choose this for new sites, or if you're confident your site works on HTTPS. You can undo this change by editing your web server's configuration. ------------------------------------------------------------------------------- Select the appropriate number [1-2] then [enter] (press 'c' to cancel):

      Выберите подходящий вариант и нажмите ENTER. Конфигурация будет обновлена, а Nginx перезапущен для применения изменений. certbot выдаст сообщение о том, что процесс прошёл успешно, и где хранятся ваши сертификаты:

      Вывод

      IMPORTANT NOTES: - Congratulations! Your certificate and chain have been saved at: /etc/letsencrypt/live/example.com/fullchain.pem Your key file has been saved at: /etc/letsencrypt/live/example.com/privkey.pem Your cert will expire on 2018-07-23. To obtain a new or tweaked version of this certificate in the future, simply run certbot again with the "certonly" option. To non-interactively renew *all* of your certificates, run "certbot renew" - Your account credentials have been saved in your Certbot configuration directory at /etc/letsencrypt. You should make a secure backup of this folder now. This configuration directory will also contain certificates and private keys obtained by Certbot so making regular backups of this folder is ideal. - If you like Certbot, please consider supporting our work by: Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate Donating to EFF: https://eff.org/donate-le

      Ваши сертификаты загружены, установлены и работают. Попробуйте перезагрузить ваш сайт с использованием https:// и вы увидите значок безопасности в браузере. Он означает, что соединение с сайтом зашифровано, обычно он выглядит, как зелёная иконка замка. Если вы проверите ваш сервер тестом SSL Labs Server Test, он получит оценку A.

      Закончим тестированием процесса обновления сертификата.

      Шаг 5 - Проверка автоматического обновления сертификата

      Сертификаты Let's Encrypt действительны только 90 дней. Это сделано для того, чтобы пользователи автоматизировали процесс обновления сертификатов. Пакет certbot, который мы установили, делает это путём добавления скрипта обновления в /etc/cron.d. Этот скрипт запускается раз в день и автоматически обновляет любые сертификаты, которые закончатся в течение ближайших 30 дней.

      Для тестирования процесса обновления мы можем сделать "сухой" запуск (dry run) certbot:

      • sudo certbot renew --dry-run

      Если вы не видите каких-либо ошибок в результате выполнения этой команды, то всё в полном порядке. При необходимости Certbot будет обновлять ваши сертификаты и перезагружать Nginx для применения изменений. Если автоматическое обновление по какой-либо причине закончится ошибкой, Let's Encrypt отправит электронное письмо на указанный вами адрес электронной почты с информацией о сертификате, который скоро закончится.

      Заключение

      В этом руководстве мы рассмотрели процесс установки клиента Let's Encrypt certbot, загрузили SSL сертификаты для вашего домена, настроили Nginx для использования этих сертификатов и настроили процесс автоматического обновления сертификатов. Если у вас есть вопросы по работе с Certbot, рекомендуем ознакомиться с документацией Certbot.



      Source link