One place for hosting & domains

      Automate Static Site Deployments with Salt, Git, and Webhooks


      Updated by Linode Contributed by Nathan Melehan

      Use promo code DOCS10 for $10 credit on a new account.

      This guide will walk through the deployment of a static site using SaltStack, which is a flexible configuration management system. The configuration files created for Salt will be version controlled using Git. Updates to your static site’s code will be automatically communicated to the production system using webhooks, an event notification system for the web.

      Setting up these mechanisms offers an array of benefits:

      • Using webhooks will keep your production website in sync with your development without any actions needed on your part.

      • Using Salt provides an extensible, reliable way to alter your production systems and minimize human error.

      • Version controlling your configuration management helps you track or revert the changes you’ve made to your systems and collaborate with others on your deployments.

      Development and Deployment Workflow

      The static site generator used in this guide is Hugo, a fast framework written in Go. Static site generators compile markdown or other content files into HTML files. This guide can easily be adapted to other frameworks.

      Two Git repositories will be created: one will track changes to the Hugo site, and the other will track Salt’s configuration files. Remote repositories will be created for both on GitHub.

      Two Linodes will be created: one will act as the Salt master, and the other as the Salt minion. This guide was tested under Debian 9, but the instructions may work with other distributions as well. The Salt minion will run the production webserver which serves the Hugo site, and the master will configure the minion’s software. The minion will also run a webhook server which will receive code update notifications from GitHub.

      It is possible to run Salt in a masterless mode, but using a Salt master will make it easier to expand on your deployment in the future.

      Note

      The workflow described in this guide is similar to how Linode’s own Guides & Tutorials website is developed and deployed.

      Before You Begin

      Set Up the Development Environment

      Development of your Hugo site and your Salt formula will take place on your personal computer. Some software will need to be installed on your computer first:

      1. Install Git using one of the methods in Linode’s guide. If you have a Mac, use the Homebrew method, as it will also be used to install Hugo.

      2. Install Hugo. The Hugo documentation has a full list of installation methods, and instructions for some popular platforms are as follows:

        • Debian/Ubuntu:

          sudo apt-get install hugo
          
        • Fedora, Red Hat and CentOS:

          sudo dnf install hugo
          
        • Mac, using Homebrew:

          brew install hugo
          
        • Windows, using Chocolatey

          choco install hugo -confirm
          

      Deploy the Linodes

      1. Follow the Getting Started guide and deploy two Linodes running Debian 9.

      2. In the settings tab of your Linodes’ dashboards, label one of the Linodes as salt-master and the other as salt-minion. This is not required, but it will help keep track of which Linode serves which purpose.

      3. Complete the Securing Your Server guide on each Linode to create a limited Linux user account with sudo privileges, harden SSH access, and remove unnecessary network services.

        Note

        This guide is written for a non-root user. Commands that require elevated privileges are prefixed with sudo. If you’re not familiar with the sudo command, visit our Users and Groups guide.

        All configuration files should be edited with elevated privileges. Remember to include sudo before running your text editor.

      4. Configure DNS for your site by adding a domain zone and setting up reverse DNS on your Salt minion’s IP address.

      Set Up the Salt Master and Salt Minion

      Before you can start setting up the Salt formulas for the minion, you first need to install the Salt software on the master and minion and set up communication between them.

      1. Log into the Salt master Linode via SSH and run the Salt installation bootstrap script:

        wget -O bootstrap-salt.sh https://bootstrap.saltstack.com
        sudo sh bootstrap-salt.sh -M -N
        

        Note

        The -M option tells the script to install the Salt master software, and the -N option tells the script to not install the minion software.

      2. Log into the Salt minion Linode via SSH and set the hostname. This guide uses hugo-webserver as the example hostname:

        sudo hostnamectl set-hostname hugo-webserver
        

        Note

        This step needs to be completed before installing Salt on the minion, as Salt will use your hostname to generate the minion’s Salt ID.

      3. Edit the minion’s /etc/hosts file and append a new line for your hostname after the localhost line; replace 192.0.2.3 with your minion’s public IP address:

        /etc/hosts
        1
        2
        3
        
        127.0.0.1       localhost
        192.0.2.3       hugo-webserver
        # [...]
      4. Run the bootstrap script on the minion:

        wget -O bootstrap-salt.sh https://bootstrap.saltstack.com
        sudo sh bootstrap-salt.sh
        
      5. Edit /etc/salt/minion on the Salt minion. Uncomment the line that begins with #master: and enter your Salt master’s IP after the colon (in place of 192.0.2.2):

        /etc/salt/minion
        1
        2
        3
        
        # [...]
        master: 192.0.2.2
        # [...]

        Note

        Linode does not charge for traffic within a datacenter across private IP addresses. If your Salt master and minion are in the same datacenter, and both have a private IP addresses, you can use your Salt master’s private IP address in this step to avoid incurring data traffic charges.

      6. Restart Salt on the minion:

        sudo systemctl restart salt-minion
        

      Salt Minion Authentication

      The minion should now be able to find the master, but it has not yet been authenticated to communicate with the master. Salt uses public-private keypairs to authenticate minions to masters.

      1. On the master, list fingerprints for all the master’s local keys, accepted minion keys, and unaccepted keys:

        sudo salt-key --finger-all
        

        The output should resemble:

          
        Local Keys:
        master.pem:  fe:1f:e8:3d:26:83:1c:...
        master.pub:  2b:93:72:b3:3a:ae:cb:...
        Unaccepted Keys:
        hugo-webserver:  29:d8:f3:ed:91:9b:51:...
        
        

        Note

        The example fingerprints in this section have been truncated for brevity.

      2. Copy the fingerprint for master.pub from the output of salt-key --finger-all. On your Salt minion, open /etc/salt/minion in a text editor. Uncomment the line that begins with #master_finger: and enter the value for your master.pub after the colon in single-quotes:

        /etc/salt/minion
        1
        2
        3
        
        # [...]
        master_finger: '0f:d6:5f:5e:f3:4f:d3:...'
        # [...]
      3. Restart Salt on the minion:

        sudo systemctl restart salt-minion
        
      4. View the minion’s local key fingerprint:

        sudo salt-call key.finger --local
        
          
        local:
            29:d8:f3:ed:91:9b:51:...
        
        

        Compare the output’s listed fingerprint to the fingerprints listed by the Salt master for any Unaccepted Keys. This is the output of salt-key --finger-all run on the master in the beginning of this section.

      5. After verifying, that the minion’s fingerprint is the same as the fingerprint detected by the Salt master, run the following command on the master to accept the minion’s key:

        sudo salt-key -a hugo-webserver
        
      6. From the master, verify that the minion is running:

        sudo salt-run manage.up
        

        You can also run a Salt test ping from the master to the minion:

        sudo salt 'hugo-webserver' test.ping
        
          
        hugo-webserver:
            True
        
        

      Initialize the Salt Minion’s Formula

      The Salt minion is ready to be configured by the master. These configurations will be written in a Salt formula which will be hosted on GitHub.

      1. On your computer, create a new directory to hold your minion’s formula and change to that directory:

        mkdir hugo-webserver-salt-formula
        cd hugo-webserver-salt-formula
        
      2. Inside the formula directory, create a new hugo directory to hold your webserver’s configuration:

        mkdir hugo
        
      3. Inside the hugo directory, create a new install.sls file:

        hugo-webserver-salt-formula/hugo/install.sls
        1
        2
        3
        
        nginx_pkg:
          pkg.installed:
            - name: nginx

        Note

        Salt configurations are declared in YAML– a markup language that incorporates whitespace/indentation in its syntax. Be sure to use the same indentation as the snippets presented in this guide.

        A .sls file is a SaLt State file. Salt states describe the state a minion should be in after the state is applied to it: e.g., all the software that should be installed, all the services that should be run, and so on.

        The above snippet says that a package with name nginx (i.e. the NGINX web server) should be installed via the distribution’s package manager. Salt knows how to negotiate software installation via the built-in package manager for various distributions. Salt also knows how to install software via NPM and other package managers.

        The string nginx_pkg is the ID for the state component, pkg is the name of the Salt module used, and pkg.installed is referred to as a function declaration. The component ID is arbitrary, so you can name it however you prefer.

        Note

        If you were to name the ID to be the same as the relevant installed package, then you do not need to specify the - name option, as it will be inferred from the ID. For example, this snippet also installs NGINX:

        hugo-webserver-salt-formula/hugo/install.sls

        The same name/ID convention is true for other Salt modules.

      4. Inside the hugo directory, create a new service.sls file:

        hugo-webserver-salt-formula/hugo/service.sls
        1
        2
        3
        4
        5
        6
        
        nginx_service:
          service.running:
            - name: nginx
            - enable: True
            - require:
              - pkg: nginx_pkg

        This state says that the nginx service should be immediately run and be enabled to run at boot. For a Debian 9 system, Salt will set the appropriate systemd configurations to enable the service. Salt also supports other init systems.

        The require lines specify that this state component should not be applied until after the nginx_pkg component has been applied.

        Note

        Unless specified by a require declaration, Salt makes no guarantees about the order that different components are applied. The order that components are listed in a state file does not necessarily correspond with the order that they are applied.

      5. Inside the hugo directory, create a new init.sls file with the following contents:

        hugo-webserver-salt-formula/hugo/init.sls
        1
        2
        3
        
        include:
          - hugo.install
          - hugo.service

        Using the include declaration in this way simply concatenates the install.sls and service.sls files into a single combined state file.

        Right now, these state files only install and enable NGINX. More functionality will be enabled later in this guide.

        The install and service states will not be applied to the minion on their own–instead, only the combined init state will ever be applied. In Salt, when a file named init.sls exists inside a directory, Salt will refer to that particular state by the name of the directory it belongs to (i.e. hugo in our example).

        Note

        The organization of the state files used here is not mandated by Salt. Salt does not place restrictions on how you organize your states. This specific structure is presented as an example of a best practice.

      Push the Salt Formula to GitHub

      1. Inside your hugo-webserver-salt-formula directory on your computer, initialize a new Git repository:

        cd ~/hugo-webserver-salt-formula
        git init
        
      2. Stage the files you just created:

        git add .
        
      3. Review the staged files:

        git status
        
          
        On branch master
        No commits yet
        Changes to be committed:
          (use "git rm --cached ..." to unstage)
        
          new file:   hugo/init.sls
          new file:   hugo/install.sls
          new file:   hugo/service.sls
        
        
      4. Commit the files:

        git commit -m "Initial commit"
        
      5. Log into the GitHub website in your browser and navigate to the Create a New Repository page.

      6. Create a new public repository with the name hugo-webserver-salt-formula:

        GitHub New Repository - Add New Salt Formula Repo

      7. Copy the HTTPS URL for your new repository:

        GitHub New Repository - New Salt Formula Repo

      8. In your local Salt formula repository, add the GitHub repository as the origin remote and push your new files to it. Replace github-username with your GitHub user:

        git remote add origin https://github.com/github-username/hugo-webserver-salt-formula.git
        git push -u origin master
        

        Note

        If you haven’t pushed anything else to your GitHub account from the command line before, you may be prompted to authenticate with GitHub. If you have two-factor authentication enabled for your account, you will need to create and use a personal access token.
      9. If you navigate back to your hugo-webserver-salt-formula repository on GitHub and refresh the page, you should now see your new files.

      Enable GitFS on the Salt Master

      Update your Salt master to serve the new formula from GitHub:

      1. Salt requires that you install a Python interface to Git to use GitFS. On the Salt master Linode:

        sudo apt-get install python-git
        
      2. Open /etc/salt/master in a text editor. Uncomment the fileserver_backend declaration and enter roots and gitfs in the declaration list:

        /etc/salt/master
        1
        2
        3
        
        fileserver_backend:
          - roots
          - gitfs

        roots refers to Salt files stored on the master’s filesystem. While the Hugo webserver Salt formula is stored on GitHub, the Salt Top file will be stored on the master. The Top file is how Salt maps states to the minions they will be applied to.

      3. In the same file, uncomment the gitfs_remotes declaration and enter your Salt formula’s repository URL:

        /etc/salt/master
        1
        2
        
        gitfs_remotes:
          - https://github.com/your_github_user/hugo-webserver-salt-formula.git
      4. Uncomment the gitfs_provider declaration and set its value to gitpython:

        /etc/salt/master
        1
        
        gitfs_provider: gitpython

      Apply the Formula’s State to the Minion

      1. In /etc/salt/master, uncomment the file_roots declaration and set the following values:

        /etc/salt/master
        1
        2
        3
        
        file_roots:
          base:
            - /srv/salt/

        file_roots specifies where state files are kept on the Master’s filesystem. This is referenced when - roots is declared in the fileserver_backend section. base refers to a Salt environment, which is a tree of state files that can be applied to minions. This guide will only use the base environment, but other environments could be created for development, QA, and so on.

      2. Restart Salt on the master to enable the changes in /etc/salt/master:

        sudo systemctl restart salt-master
        
      3. Create the /srv/salt directory on the Salt master:

        sudo mkdir /srv/salt
        
      4. Create a new top.sls file in /srv/salt:

        /srv/salt/top.sls
        1
        2
        3
        
        base:
          'hugo-webserver':
            - hugo

        This is Salt’s Top file, and the snippet declares that the hugo-webserver minion should receive the init.sls state from the hugo directory (from your GitHub-hosted Salt formula).

      5. Tell Salt to apply states from the Top file to the minion:

        sudo salt 'hugo-webserver' state.apply
        

        Salt as refers to this command as a highstate. Running a highstate can take a bit of time to complete, and the output of the command will describe what actions were taken on the minion. The output will also show if any actions failed.

        Note

        If you see an error similar to:

          
        No matching sls found for 'hugo' in env 'base'
        
        

        Try running this command to manually fetch the Salt formula from GitHub, then run the state.apply command again:

        sudo salt-run fileserver.update
        

        Salt’s GitFS fetches files from remotes periodically, and this period can be configured.

      6. If you visit your domain name in a web browser, you should now see NGINX’s default test page served by the Salt minion.

      Initialize the Hugo Site

      1. On your computer, create a new Hugo site. Make sure you are not running this command in your hugo-webserver-salt-formula directory:

        hugo new site example-hugo-site
        
      2. Navigate to the new Hugo site directory and initialize a Git repository:

        cd example-hugo-site
        git init
        
      3. Install a theme into the themes/ directory. This guide uses the Cactus theme:

        git submodule add https://github.com/digitalcraftsman/hugo-cactus-theme.git themes/hugo-cactus-theme
        
      4. The theme comes with some example content. Copy it into the root of your site so that it can be viewed:

        cp -r themes/hugo-cactus-theme/exampleSite/ .
        
      5. Edit the baseurl, themesDir, and name options in config.toml as follows; replace example.com with your own domain and Your Name with your own name:

        example-hugo-site/config.toml
        1
        2
        3
        4
        5
        6
        
        # [...]
        baseURL = "http://example.com"
        # [...]
        themesDir = "themes"
        # [...]
          name = "Your Name"
      6. Run the Hugo development server on your computer:

        hugo server
        

        The output from this command will end with a line like:

          
        Web Server is available at http://localhost:1313/ (bind address 127.0.0.1)
        
        
      7. If you view the URL from this output in a browser, you can see your new Hugo site:

        New Hugo Site - Development Server

      8. Enter CTRL-C in the terminal session on your computer to stop the Hugo development server. Open the .gitignore file and make sure public/ is listed. The default .gitignore from the Cactus theme should look like:

        example-hugo-site/config.toml

        The public directory is the result of Hugo compiling the Markdown content files into HTML. These files can be regenerated by anyone who downloads your site code, so they won’t be checked into version control.

      Push the Hugo Site to GitHub

      1. In the Hugo site directory, commit the new site files:

        git add .
        git commit -m "Initial commit"
        
      2. Create a new public repository on GitHub named example-hugo-site and copy the repository’s HTTPS URL.

      3. In the site directory, add the GitHub repository as the origin remote and push your new files to it; replace github-username with your GitHub user:

        git remote add origin https://github.com/github-username/example-hugo-site.git
        git push -u origin master
        

      Deploy the Hugo Site

      The Salt minion’s formula needs to be updated in order to serve the Hugo site. Specifically, the formula will need to have states which:

      • Install Git and clone the Hugo site repository from GitHub.

      • Install Hugo and build the HTML files from the markdown content.

      • Update the NGINX configuration to serve the built site.

      Some of the new state components will refer to data stored in Salt Pillar. Pillar is a Salt system that stores private data and other parameters that you don’t want to list in your formulas. The Pillar data will be kept as a file on the Salt master and not checked into version control.

      Note

      There are methods for securely checking this data into version control or using other backends to host the data, but those strategies are outside the scope of this guide.

      Pillar data is injected into state files with Salt’s Jinja templating feature. State files are first evaluated as Jinja templates and then as YAML afterwards.

      Install Git and Hugo

      In your local Salt formula’s repository, edit the install.sls file to append the git_pkg and hugo_pkg states:

      hugo-webserver-salt-formula/hugo/install.sls
       1
       2
       3
       4
       5
       6
       7
       8
       9
      10
      11
      
      # [...]
      
      git_pkg:
        pkg.installed:
          - name: git
      
      hugo_pkg:
        pkg.installed:
          - name: hugo
          - sources:
            - hugo: https://github.com/gohugoio/hugo/releases/download/v{{ pillar['hugo_deployment_data']['hugo_version'] }}/hugo_{{ pillar['hugo_deployment_data']['hugo_version'] }}_Linux-64bit.deb

      The first state component installs Git, and the second component installs Hugo. The second component’s sources declaration specifies that the package should be downloaded from Hugo’s GitHub repository (instead of from the distribution package manager).

      The {{ }} syntax that appears in {{ pillar['hugo_deployment_data']['hugo_version'] }} is a Jinja substitution statement. pillar['hugo_deployment_data']['hugo_version'] returns the value of the hugo_version key from a dictionary named hugo_deployment_data in Pillar. Keeping the Hugo version in Pillar lets you update Hugo without needing to update your formulas.

      Clone the Hugo Site Git Repository

      Create a new config.sls file in your local Salt formula repository’s hugo directory:

      hugo-webserver-salt-formula/hugo/config.sls
       1
       2
       3
       4
       5
       6
       7
       8
       9
      10
      11
      12
      13
      14
      15
      16
      17
      18
      19
      20
      21
      22
      
      hugo_group:
        group.present:
          - name: {{ pillar['hugo_deployment_data']['group'] }}
      
      hugo_user:
        user.present:
          - name: {{ pillar['hugo_deployment_data']['user'] }}
          - gid: {{ pillar['hugo_deployment_data']['group'] }}
          - home: {{ pillar['hugo_deployment_data']['home_dir'] }}
          - createhome: True
          - require:
            - group: hugo_group
      
      hugo_site_repo:
        cmd.run:
          - name: git clone --recurse-submodules https://github.com/{{ pillar['hugo_deployment_data']['github_account'] }}/{{ pillar['hugo_deployment_data']['site_repo_name'] }}.git
          - cwd: {{ pillar['hugo_deployment_data']['home_dir'] }}
          - runas: {{ pillar['hugo_deployment_data']['user'] }}
          - creates: {{ pillar['hugo_deployment_data']['home_dir'] }}/{{ pillar['hugo_deployment_data']['site_repo_name'] }}
          - require:
            - pkg: git_pkg
            - user: hugo_user

      The final hugo_site_repo component in this snippet is responsible for cloning the example Hugo site repository from GitHub. This cloned repo is placed in the home directory of a system user that Salt creates in the preceding components. The clone command also recursively downloads the Cactus theme submodule.

      Note

      The - creates declaration tells Salt that running the cmd command module will result in the creation of the file that’s specified. If the state is applied again later, Salt will check if that file already exists. If it exists, Salt will not run the module again.

      The require declarations in each component ensure that:

      • The clone is not run until the system user and home directory have been created, and until the software package for Git has been installed.
      • The user is not created until the group it belongs to is created.

      Instead of hard-coding the parameters for the user, group, home directory, GitHub account, and repository name, these are retrieved from Pillar.

      Configure NGINX

      1. Append the following states to your config.sls:

        hugo-webserver-salt-formula/hugo/config.sls
         1
         2
         3
         4
         5
         6
         7
         8
         9
        10
        11
        12
        13
        14
        15
        16
        17
        18
        19
        20
        21
        22
        23
        24
        25
        26
        27
        28
        29
        30
        31
        32
        33
        34
        
        nginx_default:
          file.absent:
            - name: '/etc/nginx/sites-enabled/default'
            - require:
              - pkg: nginx_pkg
        
        nginx_config:
          file.managed:
            - name: /etc/nginx/sites-available/hugo_site
            - source: salt://hugo/files/hugo_site
            - user: root
            - group: root
            - mode: 0644
            - template: jinja
            - require:
              - pkg: nginx_pkg
        
        nginx_symlink:
          file.symlink:
            - name: /etc/nginx/sites-enabled/hugo_site
            - target: /etc/nginx/sites-available/hugo_site
            - user: root
            - group: root
            - require:
              - file: nginx_config
        
        nginx_document_root:
          file.directory:
            - name: {{ pillar['hugo_deployment_data']['nginx_document_root'] }}/{{ pillar['hugo_deployment_data']['site_repo_name'] }}
            - user: {{ pillar['hugo_deployment_data']['user'] }}
            - group: {{ pillar['hugo_deployment_data']['group'] }}
            - dir_mode: 0755
            - require:
              - user: hugo_user
        • The nginx_default component removes the symlink in sites-enabled for the default NGINX config, which disables that configuration.
        • nginx_config and nginx_symlink then create a new configuration file in sites-available and a symlink to it in sites-enabled.
        • The nginx_document_root component creates the directory that NGINX will serve your Hugo site files from (when filled in with Pillar data, this will directory will look like /var/www/example-hugo-site).
      2. The - source: salt://hugo/files/hugo_site declaration in nginx_config refers to an NGINX configuration file that doesn’t exist in your repository yet. Create the files/ directory:

        cd ~/hugo-webserver-salt-formula/hugo
        mkdir files
        
      3. Create the hugo_site file inside files/:

        hugo-webserver-salt-formula/hugo/files/hugo_site
         1
         2
         3
         4
         5
         6
         7
         8
         9
        10
        11
        12
        13
        
        server {
            listen 80;
            listen [::]:80;
            server_name {{ pillar['hugo_deployment_data']['domain_name'] }};
        
            root {{ pillar['hugo_deployment_data']['nginx_document_root'] }}/{{ pillar['hugo_deployment_data']['site_repo_name'] }};
        
            index index.html index.htm index.nginx-debian.html;
        
            location / {
                try_files $uri $uri/ = /404.html;
            }
        }

        The nginx_config component that manages this file also listed the - template: jinja declaration, so the source file is interpreted as a Jinja template. The source file is able to substitute values from Pillar using the Jinja substitution syntax.

      4. Replace the content of your service.sls with this snippet:

        hugo-webserver-salt-formula/hugo/service.sls
        1
        2
        3
        4
        5
        6
        7
        8
        
        nginx_service:
          service.running:
            - name: nginx
            - enable: True
            - require:
              - file: nginx_symlink
            - watch:
              - file: nginx_config

        The nginx_service component now requires nginx_symlink instead of nginx_pkg. Without this change, the service may be enabled and run before the new NGINX configuration is set up. The - watch declaration also instructs NGINX to restart whenever a change to nginx_config is made.

      Build Hugo

      1. Append a build_script state to config.sls:

        hugo-webserver-salt-formula/hugo/config.sls
         1
         2
         3
         4
         5
         6
         7
         8
         9
        10
        11
        12
        13
        14
        15
        16
        17
        18
        19
        
        build_script:
          file.managed:
            - name: {{ pillar['hugo_deployment_data']['home_dir'] }}/deploy.sh
            - source: salt://hugo/files/deploy.sh
            - user: {{ pillar['hugo_deployment_data']['user'] }}
            - group: {{ pillar['hugo_deployment_data']['group'] }}
            - mode: 0755
            - template: jinja
            - require:
              - user: hugo_user
          cmd.run:
            - name: ./deploy.sh
            - cwd: {{ pillar['hugo_deployment_data']['home_dir'] }}
            - runas: {{ pillar['hugo_deployment_data']['user'] }}
            - creates: {{ pillar['hugo_deployment_data']['nginx_document_root'] }}/{{ pillar['hugo_deployment_data']['site_repo_name'] }}/index.html
            - require:
              - file: build_script
              - cmd: hugo_site_repo
              - file: nginx_document_root

        This state uses more than one module. The first module will download the deploy.sh file from the salt master and place it on the minion. This script will be responsible for compiling your Hugo site files. The second module then calls that script. The first module is listed as a requirement of the second module, along with the Git clone command, and the creation of the document root folder.

        Note

        The - creates option in the second module ensures that Salt doesn’t rebuild Hugo if the state is re-applied to the minion.

      2. Create the deploy.sh script in files/:

        hugo-webserver-salt-formula/hugo/files/deploy.sh
        1
        2
        3
        4
        
        #!/bin/bash
        
        cd {{ pillar['hugo_deployment_data']['site_repo_name'] }}
        hugo --destination={{ pillar['hugo_deployment_data']['nginx_document_root'] }}/{{ pillar['hugo_deployment_data']['site_repo_name'] }}

        Hugo’s build function is called with NGINX’s document root as the destination for the built files.

      3. Update init.sls to include the new config.sls file:

        hugo-webserver-salt-formula/hugo/init.sls
        1
        2
        3
        4
        
        include:
          - hugo.install
          - hugo.config
          - hugo.service

      Push the Salt Formula Updates to GitHub

      Your state files should now have these contents: init.sls, install.sls, config.sls, service.sls.

      The files present in your Salt formula repository should be:

        
      hugo
      ├── config.sls
      ├── files
      │   ├── deploy.sh
      │   └── hugo_site
      ├── init.sls
      ├── install.sls
      └── service.sls
      
      
      1. Stage all the changes you made to your local Salt formula files in the previous steps and then commit the changes:

        cd ~/hugo-webserver-salt-formula
        git add .
        git commit -m "Deploy the Hugo site"
        
      2. Push the commit to your GitHub repository:

        git push origin master
        

      Create the Salt Pillar File

      1. Open /etc/salt/master on the Salt master in a text editor. Uncomment the pillar_roots section:

        /etc/salt/master
        1
        2
        3
        
        pillar_roots:
          base:
            - /srv/pillar

        pillar_roots performs an analogous function to file_roots: it specifies where Pillar data is stored on the master’s filesystem.

      2. Restart Salt on the master to enable the changes in /etc/salt/master:

        sudo systemctl restart salt-master
        
      3. Create the /srv/pillar directory on the Salt master:

        sudo mkdir /srv/pillar
        
      4. Create an example-hugo-site.sls file in /srv/pillar to contain the Pillar data for the minion. This file uses the same YAML syntax as other state files. Replace the values for github_account and domain_name with your GitHub account and your site’s domain name:

        /srv/pillar/example-hugo-site.sls
        1
        2
        3
        4
        5
        6
        7
        8
        9
        
        hugo_deployment_data:
          hugo_version: 0.49
          group: hugo
          user: hugo
          home_dir: /home/hugo
          github_account: your_github_user
          site_repo_name: example-hugo-site
          nginx_document_root: /var/www
          domain_name: yourdomain.com
      5. Create a top.sls file in /srv/pillar. Similar to the Top file in your state tree, the Pillar’s Top file maps Pillar data to minions:

        /srv/pillar/top.sls
        1
        2
        3
        
        base:
          'hugo-webserver':
            - example-hugo-site

      Apply State Updates to the Minion

      On the Salt master, apply the new states to all minions:

      sudo salt '*' state.apply
      

      Note

      In this guide there is only one minion, but Salt can use shell-style globbing and regular expressions to match against minion IDs when you have more than one. For example, this command would run a highstate on all minions whose IDs begin with hugo:

      sudo salt 'hugo*' state.apply
      

      If no changes are made, try manually fetching the Salt formula updates from GitHub and then run the state.apply command again:

      sudo salt-run fileserver.update
      

      When the operation finishes, your Hugo site should now be visible at your domain.

      Deploy Site Updates with Webhooks

      Your site is now deployed to production, but there is no automatic mechanism in place yet for updating the production server when you update your Hugo site’s content. To update the production server, your minion will need to:

      1. Pull the latest changes pushed to the master branch of your Hugo site repository on GitHub.

      2. Run the Hugo build process with the new content.

      The deploy.sh script can be altered to pull changes from GitHub. These script changes will be made in the Salt formula repository. Then, we’ll set up webhooks to notify the Salt minion that updates have been made to the Hugo site.

      Webhooks are HTTP POST requests specifically designed and sent by systems to communicate some kind of significant event. A webhook server listens for these requests and then takes some action when it receives one. For example, a GitHub repository can be configured to send webhook notifications whenever a push is made to the repository. This is the kind of notification we’ll configure, and the Salt minion will run a webhook server to receive them. Other event notifications can also be set up on GitHub.

      Set Up a Webhook Server on the Salt Minion

      1. In your local Salt formula repository, append a new webhook_pkg state to your install.sls that installs the webhook server package by adnanh:

        hugo-webserver-salt-formula/hugo/install.sls
        1
        2
        3
        
        webhook_pkg:
          pkg.installed:
            - name: webhook

        Note

        The webhook server written in Go by adnanh is a popular implementation of the concept, but it’s possible to write other HTTP servers that parse webhook payloads.

      2. Append two new components to your config.sls:

        hugo-webserver-salt-formula/hugo/config.sls
         1
         2
         3
         4
         5
         6
         7
         8
         9
        10
        11
        12
        13
        14
        15
        16
        17
        18
        19
        20
        21
        22
        23
        24
        25
        26
        
        webhook_systemd_unit:
          file.managed:
            - name: '/etc/systemd/system/webhook.service'
            - source: salt://hugo/files/webhook.service
            - user: root
            - group: root
            - mode: 0644
            - template: jinja
            - require:
              - pkg: webhook_pkg
          module.run:
            - name: service.systemctl_reload
            - onchanges:
              - file: webhook_systemd_unit
        
        webhook_config:
          file.managed:
            - name: '/etc/webhook.conf'
            - source: salt://hugo/files/webhook.conf
            - user: root
            - group: {{ pillar['hugo_deployment_data']['group'] }}
            - mode: 0640
            - template: jinja
            - require:
              - pkg: webhook_pkg
              - group: hugo_group

        The first state creates a systemd unit file for the webhook service. The second state creates a webhook configuration. The webhook server reads the configuration and generates a webhook URL from it.

      3. Create a webhook.service file in your repository’s files/ directory:

        hugo-webserver-salt-formula/hugo/files/webhook.service
         1
         2
         3
         4
         5
         6
         7
         8
         9
        10
        
        [Unit]
        Description=Small server for creating HTTP endpoints (hooks)
        Documentation=https://github.com/adnanh/webhook/
        
        [Service]
        User={{ pillar['hugo_deployment_data']['user'] }}
        ExecStart=/usr/bin/webhook -nopanic -hooks /etc/webhook.conf
        
        [Install]
        WantedBy=multi-user.target
      4. Create a webhook.conf file in your repository’s files/ directory:

        hugo-webserver-salt-formula/hugo/files/webhook.conf
         1
         2
         3
         4
         5
         6
         7
         8
         9
        10
        11
        12
        13
        14
        15
        16
        17
        18
        19
        20
        21
        22
        23
        24
        25
        26
        27
        28
        29
        30
        31
        32
        33
        34
        35
        36
        37
        
        [
          {
            "id": "github_push",
            "execute-command": "{{ pillar['hugo_deployment_data']['home_dir'] }}/deploy.sh",
            "command-working-directory": "{{ pillar['hugo_deployment_data']['home_dir'] }}",
            "trigger-rule":
            {
              "and":
              [
                {
                  "match":
                  {
                    "type": "payload-hash-sha1",
                    "secret": "{{ pillar['hugo_deployment_data']['webhook_secret'] }}",
                    "parameter":
                    {
                      "source": "header",
                      "name": "X-Hub-Signature"
                    }
                  }
                },
                {
                  "match":
                  {
                    "type": "value",
                    "value": "refs/heads/master",
                    "parameter":
                    {
                      "source": "payload",
                      "name": "ref"
                    }
                  }
                }
              ]
            }
          }
        ]

        This configuration sets up a URL named http://example.com:9000/hooks/github_push, where the last component of the URL is derived from the value of the configuration’s id.

        Note

        The webhook server runs on port 9000 and places your webhooks inside a hooks/ directory by default.

        When a POST request is sent to the URL:

        • The webhook server checks if the header and payload data from the request satisfies the rules in the trigger-rule dictionary, which are:

          • That the SHA1 hash of the server’s webhook secret matches the secret in the request headers. This prevents people who don’t know your webhook secret from triggering the webhook’s action.
          • The ref parameter in the payload matches refs/heads/master. This ensures that only pushes to the master branch trigger the action.
        • If the rules are satisfied, then the command listed in execute-command is run, which is the deploy.sh script.

        Note

        Further documentation on the webhook configuration options can be reviewed on the project’s GitHub repository.
      5. Append a new webhook_service state to your service.sls that enables and starts the webhook server:

        hugo-webserver-salt-formula/hugo/service.sls
        1
        2
        3
        4
        5
        6
        7
        
        webhook_service:
          service.running:
            - name: webhook
            - enable: True
            - watch:
              - file: webhook_config
              - module: webhook_systemd_unit
      6. Update the deploy.sh script so that it pulls changes from master before building the site:

        hugo-webserver-salt-formula/hugo/files/deploy.sh
        1
        2
        3
        4
        5
        
        #!/bin/bash
        
        cd {{ pillar['hugo_deployment_data']['site_repo_name'] }}
        git pull origin master
        hugo --destination={{ pillar['hugo_deployment_data']['nginx_document_root'] }}//{{ pillar['hugo_deployment_data']['site_repo_name'] }}
      7. Your state files should now have these contents: init.sls (unchanged), install.sls, config.sls, service.sls. Save the changes made to your Salt files, then commit and push them to GitHub:

        cd ~/hugo-webserver-salt-formula
        git add .
        git commit -m "Webhook server states"
        git push origin master
        
      8. On the Salt master, add a webhook_secret to the example-hugo-site.sls Pillar. Your secret should be a complex, random alphanumeric string.

        /srv/pillar/example-hugo-site.sls
        1
        2
        3
        
        hugo_deployment_data:
          # [...]
          webhook_secret: your_webhook_secret
      9. From the Salt master, apply the formula updates to the minion:

        sudo salt-run fileserver.update
        sudo salt 'hugo-webserver' state.apply
        
      10. Your webhook server should now be running on the minion. If you run a curl against it, you should see:

        curl http://example.com:9000/hooks/github_push
        
          
        Hook rules were not satisfied.⏎
        
        

      Configure a Webhook on GitHub

      1. Visit your example Hugo site repository on GitHub and navigate to the Webhooks section of the Settings tab. Click on the Add webhook button:

        GitHub - Add Webhook Button

      2. Fill in the form:

        • Enter http://example.com:9000/hooks/github_push for the payload URL (substitute example.com for your own domain).

        • Select application/json for the content type.

        • Paste in the webhook secret that you previously added to Salt Pillar.

        The webhook is configured to notify on push events by default. Keep this option selected.

        GitHub - New Webhook Configuration

      3. Click the green Add webhook button to complete the setup.

      Update the Hugo Site

      1. In your local Hugo site repository, create a new post using Hugo’s archetypes feature:

        hugo new post/test-post.md
        
      2. This command creates a new partially filled in markdown document in content/post/. Open this file in your editor, remove the draft: true line from the frontmatter, and add some body text:

        example-hugo-site/content/post/test-post.md
        1
        2
        3
        4
        5
        6
        
        ---
        title: "Test Post"
        date: 2018-10-19T11:39:15-04:00
        ---
        
        Test post body text
      3. If you run hugo server in the repository directory, you can see the new post:

        Hugo Home Page - Test Post

      4. Commit and push the new post to GitHub:

        cd ~/example-hugo-site
        git add .
        git commit -m "Test post"
        git push origin master
        
      5. Visit your domain in your browser; your test post should automatically appear.

        Note

        If your post does not appear, review the Recent Deliveries section at the bottom of your webhook configuration page on GitHub:

        GitHub Webhook - Recent Deliveries

        If you click on a delivery, full information about the request headers and payload and the server response are shown, and these may provide some troubleshooting information. Editing the webhook.service file so that it starts the service in verbose mode may help.

      Next Steps

      The current Salt configuration can be used as a foundation for more complex deployments:

      • Host multiple Hugo sites by updating Pillar with further GitHub repositories.

      • Host different kinds of static sites by changing the Salt formula to support them.

      • Load balance your site by creating more minions and apply the same Pillar data and Salt states to them. Then, set up a NodeBalancer to direct traffic to the minions.

      • Set up a separate development branch and development server with Salt’s environments feature.

      More Information

      You may wish to consult the following resources for additional information on this topic. While these are provided in the hope that they will be useful, please note that we cannot vouch for the accuracy or timeliness of externally hosted materials.

      Join our Community

      Find answers, ask questions, and help others.

      This guide is published under a CC BY-ND 4.0 license.



      Source link

      A Beginner’s Guide to Crafting the Perfect Blog — From Site Creation to Broadcasting Your Brand


      Back in the day, blogging essentially amounted to taking the stage in an empty theater. The spotlight shone on you as you stood behind the microphone and embarked on a soliloquy about your day. Maybe your dog did something funny and adorable, or perhaps you had a handful of vacation stories and photos to share. Maybe your aging water heater finally keeled over and died, setting off a tragically comedic series of home improvement projects.

      The availability and accessibility of personal web space in the mid-2000s gave rise to countless bloggers — but not many readers or business opportunities. Blogs typically added up to online diaries shared among close friends and family members, words thrown into the ether.

      via GIPHY

      Over the last several years, however, blogging has shifted from a self-serving ritual to an often fruitful endeavor. Several top blogs have turned into leading voices of industry and now amass hundreds of thousands of dollars each month.

      But blogging success isn’t just reserved for the Arianna Huffingtons of the world. From personal finance and fitness to food and fashion, individual writers can use their voice (well, their fingers and keyboard) to build a brand and expand it into a livelihood.

      However, don’t let the technical aspects of creating an online presence weigh you down or prevent you from starting. Coming up with your blogging idea and goals is plenty intimidating; once you’ve overcome that big hurdle, take a look at the steps we’ve outlined below to see how to make your dream a reality.

      Step 1: Pick Your Platform

      You know what you want to say, but how will anyone hear you? Your new blogging venture will face a critical early test when you choose which venue to share your point of view. While the writing, editing, and publishing features found in most blogging platforms are mostly the same, your experience and effectiveness will be significantly impacted.

      Website builders offer a beginner-friendly way to get online, but many of the big-name services tend to emphasize drag-and-drop design over providing a substantive and dynamic writing environment. Blogging is a bit of an afterthought, more of an extra feature thrown into the mix.

      Third-party publishing platforms like Blogger, Tumblr, or Medium emphasizes content and community, but it’s easy for authors to get lost in the crowd. Your brand becomes absorbed by the platform displaying your work.

      Even though all these options come with free or low-cost options, expenses can get a bit out of hand once you add the features you need to be successful (a custom domain name, for instance). You tend not to have as much flexibility as you’d think.

      Worst of all, those platforms own your content. The proprietary programs often make it difficult for you to download your content, and you won’t be able to transfer your site anywhere else without completely rebuilding. Granted, the companies mentioned likely aren’t disappearing anytime soon, but even promising startups can vanish in the blink of an eye — and take your blog with them.

      Turning to an open-source content management system like WordPress immediately solves all these woes. This free software powers nearly a third of the web, making it the most popular and trusted publishing tool.

      With a history rooted in blogging, WordPress balances writing tools with beautiful customizable designs (that will soon get even easier to use with the debut of Gutenberg and blocks). Both hobbyists and Fortune 500 companies use WordPress to build their brand and foster interactions with readers. You maintain complete control over your site and content. Trust us: go with WordPress.

      Want to learn more about WordPress? Check out our WordPress tutorials.

      Step 2: Set the Stage With a Domain Name and Hosting

      Although you can dip a toe into WordPress by using the all-in-one WordPress.com, we think self-hosted WordPress (found at WordPress.org) is the way to go. Hosting your website files with a trusted provider like DreamHost gives you extra security and stability, along with unlimited growth opportunities and friendly support.

      What’s the difference between WordPress.com and WordPress.org? Turns out, it’s big, especially when you want full control over your website.

      Most new bloggers will be well served with a shared web hosting plan. The configuration is the thankfully the cheapest option, but smaller price tags can open the door for performance issues or crummy customer service, depending on your provider.

      Instead of signing up with a generic web hosting plan, explore the specialized features WordPress hosting introduces. If you’re worried about the tech stuff becoming too involved or complicated, purchase managed WordPress hosting and let the experts take care of it. For more information on the similarities and differences between traditional web hosting and the managed WordPress variety, check out this resource from HostingAdvice.com.

      Once hosting is acquired, it’s time to take the first big, demonstrable step in establishing your blog! Many new hosting accounts, including ones through DreamHost, come with a free domain name registration. This is the URL your readers will associate with you and your content, so you’ll want to make this count! Hopefully, you already have a brand name in mind, but don’t be crushed if it’s not available as a domain. Some tips to consider when domain shopping:

      • Use descriptive keywords to describe your blog
      • Look for something short, pronounceable, and easy to spell
      • Avoid hyphens and other punctuation
      • Don’t be afraid to try different domain extensions
      • See if your name is also available on social media
      • Make sure there are no trademark or copyright infringements

      Step 3: Find a Theme and Customize Your Look

      Many hosts have simplified the WordPress installation process to just a click or two, but DreamHost has even eliminated that step. We’ll install WordPress for you, along with a handful of rock-solid themes and plugins to get you started. Finding the right theme or design is critical for your blog’s success, as it connects your readers with your content and quickly informs their first impression of your brand.

      Instead of getting bogged down in color schemes and typography, focus on functionality. Good blog themes should make your content easy to find. As such, pay attention to the information you display above the fold:

      • Is your navigation menu there?
      • What about a search box?
      • Recent or popular posts?

      Don’t feel like you need to make some big splash with your theme — clean, simple, useful designs always win.

      Obviously, your blog’s landing page and individual posts will garner the lion’s share of looks, but don’t forget about creating a visually engaging and useful design for an about page and a contact page. An about page helps build trust with your readers and enables you to share your personality and credentials, along with the blog’s mission and aspirations.

      Your theme and your content should work together and add value, not compete for attention. Fonts should be large and readable. Make sure the responsive or mobile-friendly versions of your site don’t hide important information on smaller screens. Instead of playing with the fun parts of web design, such as colors, imagery, and animations, concentrate on user experience. After all, your blog’s design is for your readers, not you!

      Step 4: Construct a Keyword-Driven Content Strategy

      Sure, you know you want to blog. But are you sure you’re treating this as a possible business venture and source of income (and not as a self-satisfying bout of verbal preening)? Briefly put your writing talents aside and come up with a business plan for your blog that avoids these common mistakes.

      For instance, how often do you plan on publishing a new post? Temper the initial excitement and avoid committing to an unsustainable writing schedule. Seek consistency, both in terms of frequency and tone. Your personality and chosen topic area will likely shape the voice you naturally bring to your content, but don’t lose sight of your target audience. Your readers’ demographics, locations, interests, and habits all offer hints as to what information will be the most useful and entertaining.

      Take the guesswork out of your writing prompts by engaging in a healthy bit of keyword research. In addition to the obvious benefits to search engine optimization and higher rankings, keyword research reveals what your target audience is actually looking for. Your blog might be the best content on the web, but it’s all largely for naught if Google can’t find it. If a tree falls in the forest and no one is around to hear it, does it make a sound?

      Instead of jumping straight into the deep end with high-value — and highly competitive — broad search terms, identify a handful of more specific searches that you can build a base around. Don’t write content around the area’s best restaurants; craft your posts around, say, the coziest Italian restaurant that’s the best spot to bring a date. The experts at Moz do a great job of explaining a straightforward, easy-to-follow method of keyword research.

      Step 5: Work Ahead With Writing

      Once you have a healthy list of topics to explore, it’s time to finally get to work! Are you surprised that writing is such a small part of establishing a successful blog? Because writing is theoretically the part that comes most natural to you, we’re just helping establish the guidelines through which to funnel your creativity and steer your success.

      For starters, you’ll want to publish a few posts before you officially launch your blog. Give readers a glimpse of what they can expect from your brand by covering a handful of topics in the voice and tone you envision using for the long haul. This enables your visitors to connect with you more personally and gain insights and information beyond the generic, “Hey, I started a blog” post.

      via GIPHY

      You might be chomping at the bit to get started blogging, but channel that excitement in ways that will keep that momentum going long after the initial rush wears off. In addition to the three to five posts you’ll publish, try to have another five to 10 posts written and saved in drafts. Beyond that, maintain a list of ideas or keywords you’ll want to write about in the future. By stocking up on content and topics, you’ll be poised to handle any bout of writer’s block that emerges.

      As for the content itself, find a schedule that works best for you. Publishing only two or three new posts a week is perfectly acceptable (that’s what we aim to do on the DreamHost blog). Daily articles sound great in theory, but first you need to find out if that is the right amount of content for your audience. Then take your time working up to that cadence. Spend the extra time formatting, proofreading, and otherwise perfecting each post.

      Step 6: Build Interactions and Boost Your Following

      Once your new blog is open for business, now it’s time to start attacking the second part of this post’s headline: broadcasting your brand. Just as the quality of your content won’t matter if Google can’t find you, the same can be said for your audience. Ideally, you set up your blog’s social media accounts as you worked on the site and starter content (remember when we listed social media availability as part of a strong domain name?).

      Naturally, you’ll frequently rely on your brand’s social media profiles to share new blog posts, but don’t resort to mindlessly copy/pasting links into your feed. Many of your same content creation and brainstorming exercises for your blog should also be used toward your social media: How can you be engaging, entertaining, and relevant to your followers? Find compelling images and other visual elements to accompany your posts; graphics alone can lead to more than 30 percent more clicks and visits on social media. Pose questions to your readers and lend timely insights into trending issues.

      Be sure to keep in mind that interactions with readers don’t (and shouldn’t) need to happen away from your blog. Social media networks connect broad swaths of people, but the most important audiences to focus on are the ones who have already found you. Turn your readers into brand advocates by creating engaging opportunities to interact and return to your blog. You can bridge the gap by making it easy for visitors to share their favorite post on Facebook and Twitter, of course, but consider allowing them to comment directly on the post — and be sure to respond to their questions and opinions. Doing so humanizes your brand and deepens the relationship with your readers.

      Consider capturing readers’ attention by flipping the relationship. Instead of sitting back and hoping for readers to come to your blog, set up an email newsletter or subscription and collect people’s addresses. That way, you can more actively get your content to the front and center, rather than waiting for someone to browse your blog’s way. This can easily be accomplished with an email marketing platform that provides embeddable code that can be placed in a widget on your blog’s sidebar or footer. Alternatively, consider a WordPress plugin that pops open a window directly asking for engagement. While these can be extraordinarily effective, beware of the fine line between user engagement and dark UX practices.

      Step 7: Analyze Analytics and Tweak Your Tactics

      So now your blog is a buzzing hive of activity. Readers are zipping around from one post to the next. Or maybe they’re checking out your About Page. Or instead of reading a post until the end, they’re just glancing at the headings. Maybe they’re not even opening a post.

      You’ll never know for sure until you look at analytics or the data that shows where visitors come from, how they move around their site, and why they leave. Google Analytics is the go-to (and free!) service that can provide a wealth of information about your audience and your site’s performance. Pageviews can identify your most popular blog post over a certain period, for instance, while a high bounce rate (the percentage of users who leave a site quickly after viewing only one page) may indicate some design or content changes could be in order.

      As you learn how long your readers stay on your blog and where they go, you might discover they don’t interact with your website quite how you anticipated. Find where the common hangups are and make the related tweaks to your navigation menu, read more links, and other interaction points. By solving your first few users’ problems, you’re paving the way for more and more readers.

      Do you have any questions about crafting the perfect blog? Join the DreamHost Community and let’s talk shop!



      Source link

      How This Writer Set up a DreamHost Site (In Under an Hour)


      Let’s talk truth: The world is online. If a business or company doesn’t have a functional and appealing online presence, it’s unlikely you’re going to want to engage with them. And if you are a business, a working website is critical to the success of your company. It’s 2018! If your business doesn’t have a website by now, it should.

      As a writer, I knew I needed my own piece of internet real estate if I wanted to market myself, and ideally, to advance my career. I needed to be searchable and have a branded space populated with content to showcase my work.

      The problem? Well, I’m a writer, not a tech wiz. I had no clue where to begin.

      Maybe you’re just like me — a rookie interested in getting yourself out there (virtually), but unsure of where to begin, feeling intimidated by the technological steps of setting up a website.

      Let’s ride this wave together, shall we? In this post, I’ll share my beginner-friendly, step-by-step process of getting a killer website set up easily with DreamHost, and how I got up and running in under an hour. I promise — you can do it, too. Let’s get started!

      Ready to carve out your online presence? Start by choosing the right hosting plan for your business!

      What Do You Need in a Web Host?

      With some basic research, I learned that I not only needed to create my website, but I also needed a web host to get my site on the internet. It’s less confusing than it sounds — simply put, a web host is a provider that gives you server space so your website can be found on the web. So, a web host is a pretty vital tool.

      As I was starting the process, I wasn’t about to pick any ol’ web host. I needed quality. I needed ease. And especially as a beginner, I needed support. Based on the needs of my site I developed a requirement list — i.e., what should my hosting provider offer me as a website owner? Here were my five must-haves.

      1. Room to Grow

      Websites are not one-size-fits-all. Some get heavy traffic and need customized e-commerce options; others cater to smaller crowds. I needed a hosting provider that offered a variety of options, tailored to my current needs, while providing flexibility for growth over time. I needed choices.

      2. Quick and Easy Set Up

      If at all possible, I wanted to avoid the advanced-degree-required learning curve for setting up a beautiful website. I’m a beginner, not yet fully versed in the universal language of web development. Plus, like many of you, I’m crunched for time. I needed to be able to set up a great-looking site during my kids’ nap time.

      3. Budget-Friendly Options

      I didn’t want my hosting service to cost an arm and a leg — hey, I’ve got bills, too! I needed an easy-on-the-wallet hosting option that still offered me professional service and quality hosting. A web host, while still an investment, shouldn’t break the bank.

      4. WordPress Compatibility

      Because I’m already familiar with the CMS of WordPress — having started a bunch of this-and-that blogs in the past — I wanted my web host to have WordPress compatibility (again, trying to avoid learning curves here). I wanted to be able to keep my comfortable WordPress surroundings and hit the ground running without any hiccups.

      5. Strong Customer Support

      Even with an easy-to-use web host, I knew there would be times where I would be banging on my keyboard when things went wrong. I needed a web host with all-access customer service for questions and comments. I needed a provider that would be supportive at every step of my web journey.

      So, Why DreamHost?

      With my hosting shopping list in mind, it wasn’t hard to single out DreamHost as my top choice for web hosting. Why? This award-winning web host is a one-stop-shop provider featuring an easy-to-use control panel, 24/7 support, extensive and flexible plan options, and lots more —  all at an affordable cost. Plus, DreamHost is officially recommended by WordPress! Can’t beat that stamp of approval.

      DreamHost’s Shared Hosting gives you everything you need to thrive online. Sign up today!

      How I Set Up My DreamHost Site

      So, what’s it actually like to set up a website with DreamHost? Whether you’re considering DreamHost as the hosting provider for your website or you’re currently using another service, know that DreamHost can be an A+ option for you, no matter the needs of your site. Let’s walk step-by-step through the process of setting up a website with DreamHost — visuals included!

      Picking a Plan

      Because of my newbie status, I knew I wouldn’t be expecting Cyber Monday amounts of traffic on my site (at least, not right now. A girl can hope, right?) So a Shared WordPress Hosting Starter plan felt like the right place for me to start — and it could be for you too, if you’re an individual or small business just trying to get your name out there.

      Next: creating a DreamHost account. Easy-peasy! (Don’t forget to choose a strong password! No 1234 here).

      Choosing a Domain

      As if you needed yet another reason why DreamHost is the bomb.com, choosing a domain is easy. It’s also included free with one-year hosting plan packages. Score!

      Because I wanted to brand myself and my freelance writing business, I chose my name as my domain name; luckily, it wasn’t taken. If you’re a small business, your domain will likely be your business name. But if you need options or want to get creative, make sure to brush up on the SEO best practices for domains before you commit.

      Choosing a Payment Plan

      Now onto the dollars and cents. As I mentioned, money was a factor for me in deciding which web host to use. With shared hosting and other plans, you can choose month-to-month payment plans or annual options. To save a little extra $$$, I chose a yearly plan to get things started — a good middle ground. If you just want to give your plan a try, select the monthly option. If you’re more confident, go for three years — it’s easily the best value at $7.95 a month.

      Want to know how much you’ll ultimately pay? Keep an eye on the top right corner of your browser during set-up. DreamHost is transparent about pricing —  “the money part” will keep you clued in to what your total payment will be.

      Once you select any additional options you might want, you pay up, and voila! Your DreamHost plan is set up.

      Now you can access your DreamHost dashboard, where you’ll find account details and manage additional setups. Here, you can register your domain, set up mail (yes, you can get a designated email that matches your domain!), and install apps. For me, the next step was to get WordPress installed.


      So where to do that?

      Getting WordPress Set Up

      One-Click Installs on the left navigation panel will take you where you need to go. WordPress installation is lightning-fast. With the installation complete, I logged into WordPress and get started customizing my site theme and creating content.

      Designing Your Site and Creating Content

      WordPress has tons of theme options — both free and paid — and scanning through options was (surprisingly) fun. I got to match my theme to the feel I wanted my website to have. You can even upload other compatible themes you’ve purchased or downloaded from other sites. I chose CoupLite from Themes Kingdom and uploaded it in the Themes panel.

      FYI: DreamHost has an extensive library of help articles on tons of WordPress-related topics!

      Now, it was time to start creating. From the Posts section, I started writing blog posts, outfitting them with images and selecting categories.

      I’m no photographer so I needed some images that I could integrate with my site cheaply. I found beautiful royalty-free images on the web and did some basic editing.

      Now I could start fine-tuning my design, implementing expert blogging tips, setting up plugins, and polishing my posts.

      Presenting: my website!

      Showcase Your Winning Website

      Truly, DreamHost makes setting up a site quick and painless. (Let’s be honest: there’s enough in the tech world that’s confusing.) Anyone — seriously, all skill levels — can create a professional-looking site without sacrificing tons of time or money.

      If you’re still on the fence: what’s keeping you? You can do it in 60 minutes or less too.



      Source link