One place for hosting & domains

      Should I Switch Web Hosts? How to Know When It’s Time to Migrate Your Site


      When it comes to starting a website, web hosting is one of the most crucial yet most confusing aspects to tackle. With dozens of providers on the market, it can be hard to cut through the noise and figure out which one offers the best plan for you.

      Fortunately, several signs will make it clear when it’s time to move to a new host. While they’re not so pleasant to deal with in the moment, these issues may lead you to a better service provider that can help you boost your site’s success.

      In this post, we’ll discuss these signs and how to spot them on your website. Then we’ll explain how to migrate your site to a new web hosting platform. Let’s get started!

      Have a website? We’ll move it for you!

      Migrating to a new web hosting provider can be a pain. We’ll move your existing site within 48 hours without any interruption in service. Included FREE with any DreamPress plan.

      How to Know When It’s Time to Migrate (6 Tell-Tale Signs)

      It’s possible you’ve been experiencing problems with your website for a while now without really knowing why. In some cases, it may be that your web hosting provider isn’t a good fit for your website. These six signs will let you know it’s time to switch web hosts.

      1. You’re Experiencing More Downtime Than Usual

      Any time your website is unavailable to users, it’s considered ‘down.’ Even if your site is only unavailable for seconds at a time, it could cause serious problems. For starters, downtime makes your website appear unreliable and low-quality to both users and search engines.

      If your site is experiencing frequent outages, your users will come to find they can’t rely on it to be available when needed. The Google algorithm will account for this, and your search engine rankings will fall as well, hurting your site’s visibility.

      Plus, if your site generates revenue, you’ll be missing out on income every time your site has an outage. If your site is down often or for long periods of time, you could be losing hundreds or even thousands of dollars. When you’re running an online store, uptime truly affects your bottom line.

      Web hosting is one of the most common causes of website downtime, as there are many ways in which your server can impact your site’s availability, including:

      • The quality and reliability of your hosting equipment
      • The type of server your website is on, as shared servers tend to become overloaded more quickly than other types of servers.
      • Your host’s security features, since malicious attacks can lead to downtime.

      So, if you keep finding your website is down, there’s a fair chance your host may have something to do with it. Moving to a more reliable server is the best thing for your site in a situation like this.

      2. Your Website’s Loading Speed Is Slow

      Site speed is also key to Search Engine Optimization (SEO), users’ opinions of your site, and your conversion rate. It’s wise to test your site’s speed every once in a while using tools such as Google PageSpeed Insights and Pingdom to make sure your loading times are staying low and to fix any performance issues.

      Pingdom’s results screen.

      While a crowded server can certainly slow your loading times, your server’s location also plays a role in how fast your site delivers information to visitors. Servers located far away from end users aren’t able to serve them content as quickly.

      An easy way to determine if this is the case for your website is to use Pingdom to test your site speed from a variety of locations. If your site loads quickly from some places yet takes a long time to load in others, you’ll know server location is causing speed issues for users in those regions.

      If your host only has servers in one location and doesn’t offer a Content Delivery Network (CDN), it’s almost guaranteed that some portion of your users will experience less-than-ideal site speed. It may be worth looking into hosts with more or different locations, or ones offering a CDN.

      3. Customer Service Isn’t Helpful

      A solid relationship with your web host is priceless. For starters, there are going to be times when server-related errors occur on your site. In these instances, you’ll need to be able to get ahold of your host quickly to resolve the issue and get your site back up. Plus, you may sometimes have questions about billing or other account details.

      However, the best hosts also offer support in other areas of website management. For example, many hosts provide troubleshooting guidance for different types of errors on your website or support for platforms such as WordPress.

      If your host is difficult to get in touch with, provides inadequate solutions, or doesn’t offer support in areas directly related to your hosting account, consider switching to a new provider. While you may be able to get by without quality customer support, at some point, you’ll have to reach someone for help with a server-related problem, so you’ll want a reliable team at your back.

      4. You Need More Space Than Your Current Provider Can Offer

      Most websites start small and grow over time. Your current host may have been a great fit when you were first launching your site, but if your traffic levels have increased significantly, this may no longer be the case.

      As your site accumulates more recurring users, you’ll need a server that can handle more traffic as well as more and larger website files. Moving from shared hosting to a dedicated server can help, but switching hosts can often provide a greater benefit.

      Some providers specialize in shared or Virtual Private Network (VPN) hosting and may not offer dedicated servers. As such, if your site continues to grow, you’ll need a dedicated web hosting service at some point — so a switch may be inevitable.

      Other hosts may have dedicated servers available, but still not offer as much storage as you need. Ultimately, you’ll want to compare plans between companies to see which one offers the most space for the best price.

      5. It’s Getting Too Expensive to Stay With Your Current Host

      Web hosting is a recurring expense. It’s also sometimes the largest expense associated with running a website, especially for WordPress users working with a free Content Management System (CMS) and mainly free plugins and themes.

      It’s true that you often get what you pay for with hosting. However, there are also times when an expensive plan isn’t necessary. If your site is still small and not using the amount of server space you’re paying for, or if your current hosting plan comes with several features you never touch, you’re probably paying too much.

      There’s no sense in breaking the bank to host your website when there are plenty of affordable options available. For example, we offer high-quality managed WordPress hosting plans for as low as $16.95 per month.

      If you’re shelling out more money for web hosting than what your website brings in, you might want to consider downsizing or switching hosts to stay within your budget. Plus, it never hurts to pocket a little extra cash each month.

      6. Server Security Is Sub-Par

      As we mentioned earlier in this post, hosts are responsible for securing their servers. Not every provider is as diligent as they should be when it comes to security, and hackers will sometimes exploit weaknesses in your server to gain access to your site.

      This can be detrimental to your website for multiple reasons, including:

      • The loss of parts or all of your site due to a malicious attack that destroys key files and data.
      • Compromised user data, including sensitive information such as private records and credit card details.
      • Decreased credibility, as users will see your site as less reliable if it’s hacked.

      Investing in secure hosting is a smart move. Even if you have to pay a little extra or go through the trouble of migrating to a new host, you’ll save yourself a lot of trouble down the line.

      Some security features you may want to keep an eye out for are Secure Sockets Layer (SSL) certificates, malware scanning, and server firewalls. Of course, no matter how secure your server is, you should always follow security best practices for your site itself, too.

      How to Migrate Your Website to a New Hosting Provider

      If you’ve considered the signs mentioned above and determined you should switch hosting providers, you’ll need to migrate your website. This requires you to copy all your website’s files and move them to your new hosting account.

      Typically, the migration process is pretty involved. You’ll have to contact your current host, back up your site files, then use Secure File Transfer Protocol (SFTP) and a client such as FileZilla to connect to your new server and upload your files. You’ll also want to consider transferring your domain since there are benefits to keeping your domain registration and web hosting under one roof.

      As you might imagine, there are a lot of things that could go wrong during this process. For example, corrupted backups are always a possibility, and using SFTP still poses a risk to your site’s files as you could mistakenly delete some or all of them (we recommend users always have a recent backup of their site on hand).

      These things considered, it’s helpful if you can get an expert on board to migrate your site for you. Fortunately, if you’re a WordPress user and have decided to switch to DreamHost, our managed WordPress hosting plans include free website migration services.

      DreamHost’s WordPress migration services.

      We’ll handle moving your site at no extra cost. If you’d prefer one of our shared hosting plans or have a website built without using WordPress, never fear. You can still take advantage of our migration service for just $99.

      Our migration experts will get your site moved to your new hosting account within 48 hours of your request. You’ll also avoid downtime altogether, so you don’t have to worry about negatively impacting your users’ experience while you move your site and get acquainted with the DreamHost control panel.

      Looking for a New Hosting Provider?

      We make moving easy. Our hassle-free, high-performance WordPress hosting includes a FREE professional migration service ($99 savings)!

      Switching Web Hosts

      Hosting can be one of the most confusing aspects of owning a website. With so many options to choose from, it can be difficult to know if your web hosting provider is the best one available for your needs.

      If you’ve noticed these issues on your website and have decided it’s time for a change, consider checking out our DreamPress hosting plans. Our managed WordPress hosting service will provide you with the speed, support, and security your WordPress site needs. Plus, you’ll be able to use our site migration services for free.



      Source link

      3 Solutions for Converting Your WordPress Site into a Mobile App


      Nowadays, a lot of people interact with the web mostly by using mobile devices. That means it’s more important than ever to provide a quality mobile experience. Otherwise, you risk alienating a large part of your potential user base.

      There are many ways you can improve the overall experience for your mobile users. For example, you can design a responsive website so that it looks (and works) perfectly on smaller devices. You can also go a step further and convert it into a fully-working app.

      In this article, we’ll talk about why converting your website into a WordPress mobile app can be an excellent idea for some site owners. Then we’ll discuss several tools and techniques that will enable you to do so, and discuss how to pick the right one for your needs. Let’s talk apps!

      Why Your WordPress Company Site May Need a Mobile App

      When it comes to user experience, responsive design is king. We’ve previously covered why you should create a mobile-friendly site (and how to do it), but you can also create a mobile app version of your site. Let’s go over some of the reasons you might want to use this approach:

      • Apps provide a more native experience for mobile devices.
      • You can use notifications to stay in touch with your user base.
      • If you use subscriptions, they can be managed via mobile payment systems.

      That said, an app is not a replacement for a mobile-friendly website, and vice-versa. Ideally, you’ll have both, which will enable you to maximize your potential audience. After all, some people don’t want to install any additional apps on their phones, whereas others vastly prefer the experience an app provides over that of a mobile website.

      It’s important to understand, however, that creating a mobile app isn’t particularly easy. Depending on what features you want to include, you may need a background in development, or you’ll have to hire someone to help you get the project off the ground. That process, as you might imagine, can get expensive.

      The good news is that if you’re using WordPress, you get access to multiple tools you can use to create a mobile app version of your website. There is a range of options that vary in price and ease of use, so you can pick the approach that’s best suited to your needs.

      3 Solutions for Converting Your Company WordPress Site into a Mobile App

      While there are many ways to create WordPress mobile apps, the following methods are three of the most common and accessible choices. Let’s look at each, in turn, to help you decide which ones you should consider. We’ll start with the simplest solution.

      1. Use a WordPress Plugin to Generate Your App

      As a WordPress user, you’re probably familiar with using plugins to implement cool features and functionality to your website. However, what you may not know is that you can use plugins to create a fully-working WordPress mobile app.

      There are a few tools that can accomplish this, but let’s focus on one of the most popular: AppPresser.

      AppPresser plugin.

      First, it’s important to note that the AppPresser plugin by itself doesn’t enable you to generate a mobile app. You’ll also need to sign up for a paid AppPresser account, which will be linked to your WordPress website through the plugin.

      Once you have both pieces in place, you can customize your mobile app from within the AppPresser platform and generate installable files for both Android and iOS when you’re done.

      AppPresser app creation and customization process.

      The app creation process is simple – you get to use a builder that feels just like the WordPress Customizer. However, as you might imagine, there are limitations to using a tool like this. Since you’re not building an app from scratch, you get a small set of features to play with. If you’re looking to create an app with very specific functionality, using a plugin probably isn’t the right approach for you.

      Ultimately, using a plugin to generate a mobile app for your WordPress site makes the most sense for projects that don’t require a lot of advanced functionality. For example, AppPresser would be a great choice for blog and news apps. It also handles e-commerce reasonably well, which makes it a useful option for those running a store on a WooCommerce website.

      The AppPresser plugin itself is free, but as we mentioned, you’ll need to sign up for an account on the platform. A basic AppPresser account, which supports one app (for both iOS and Android) will cost you $228 per year.

      Be Awesome on the Internet

      Join our monthly newsletter for tips and tricks to build your dream website!

      2. Opt for a Solution Designed for Companies and Professional Projects

      Of course, if you’re working on a company site, your needs are different than those who are creating mobile apps for blogs or online stores. Choosing a tool explicitly designed with companies in mind can help you create an app with features that are well-suited to your needs.

      Consider Appful, for example.

      Appful content app.

      This solution can convert your website and social media posts into a powerful content app for connecting with customers and employees. Features such as white labeling, full-service maintenance, and scalability make it highly suitable for growing companies. In fact, it powers apps for several well-known organizations, including Greenpeace, PETA, and even the United Nations.

      Appful works similarly to AppPresser, in that you’ll connect to the platform using a dedicated WordPress plugin. Then, you get access to a set of tools you can use to design a mobile app version of your site and customize its functionality. Only in this case, you’ll receive an assortment of useful templates that enable you to create a Minimum Viable Product (MVP) faster.

      Preview of the mobile app version of a website.

      On top of that, Appful also includes several other handy features, including support for offline reading, integration with Google Analytics and Apple watches, and more. Plus, the developers can also help you design a more customized app if you need specialized features, which makes this a solid middle ground between using a plugin and working with an agency (which we’ll talk about next).

      Overall, this approach offers a more user-friendly experience than most other tools. Creating a WordPress mobile app using Appful is a mostly painless process, and the service will even take care of publishing your app to the Android and iOS stores for you. Plus, you don’t need to pay to use the service until that point, which means there’s no pressure. Prices vary depending on the scope of your app and are available by request.

      3. Work With an Agency to Develop Your WordPress App

      Naturally, a third option is to hire someone to get the job done for you. When it comes to WordPress mobile apps, you’ll find no shortage of freelancers and agencies willing to take on the project — no matter the scope. This can save you a lot of time.

      Of course, hiring professional and talented developers is seldom cheap. Developing even a simple app can easily cost you thousands of dollars. The upside is that you’re not limited by what an app builder can do. If you work with an agency that knows what it’s doing, it should be able to advise you on what’s possible and what isn’t, and help you bring your vision to life.

      Considering the costs associated with this approach, we can only recommend it if you have a very large budget, and you need an app version of your WordPress website that includes functionality you can’t add using DIY tools. For simpler projects, hiring an entire agency or even a couple of freelancers might not be particularly cost-effective. If you do decide to hire out, there are plenty of places to find WordPress developers and agencies.

      Professional Website Design Made Easy

      Make your site stand out with a professional design from our partners at RipeConcepts. Packages start at $299.

      Mobility Matters

      A lot of your website’s visitors will be using mobile devices. To provide them with the best possible experience, you can create a streamlined, app-based version of your WordPress website. Depending on what tool you use, you should be able to include all the same functionality your website offers, while creating an experience that feels much more native to mobile browsers.

      Do you have any questions about how to get your WordPress mobile application off the ground? Join the DreamHost Community and let us know!



      Source link

      Deploy a WordPress Site Using Terraform and Linode StackScripts


      Updated by Linode Contributed by Linode

      Linode’s Terraform provider supports StackScripts. StackScripts allow you to automate the deployment of custom software on top of Linode’s default Linux images, or on any of your saved custom images. You can create your own StackScripts, use a StackScript created by Linode, or use a Community StackScript.

      In this guide you will learn how to use a Community StackScript to deploy WordPress on a Linode using Terraform.

      Caution

      Following this guide will result in the creation of billable Linode resources on your account. To prevent continued billing for these resources, remove them from your account when you have completed the guide, if desired.

      Before You Begin

      1. Install Terraform on your computer by following the Install Terraform section of our Use Terraform to Provision Linode Environments guide.

      2. Terraform requires an API access token. Follow the Getting Started with the Linode API guide to obtain one.

      3. If you have not already, assign Linode’s name servers to your domain at your domain name’s registrar.

      4. Browse the existing StackScripts Library to familiarize yourself with common tasks you can complete with existing StackScripts.

      Create a Terraform Configuration

      Terraform defines the elements of your Linode infrastructure inside of configuration files. Terraform refers to these infrastructure elements as resources. Once you declare your Terraform configuration, you then apply it, which results in the creation of those resources on the Linode platform.

      Create the Terraform Configuration File

      1. Ensure that you are in the terraform directory.

        cd ~/terraform
        
      2. Using your preferred text editor, create a Terraform configuration file named main.tf to hold your resource definitions:

        ~/terraform/main.tf
         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
        38
        39
        40
        41
        42
        43
        44
        
        provider "linode" {
            token = "${var.token}"
        }
        
        resource "linode_sshkey" "my_wordpress_linode_ssh_key" {
            label = "my_ssh_key"
            ssh_key = "${chomp(file("~/.ssh/id_rsa.pub"))}"
        }
        
        resource "random_string" "my_wordpress_linode_root_password" {
            length  = 32
            special = true
        }
        
        resource "linode_instance" "my_wordpress_linode" {
            image = "${var.image}"
            label = "${var.label}"
            region = "${var.region}"
            type = "${var.type}"
            authorized_keys = [ "${linode_sshkey.my_wordpress_linode_ssh_key.ssh_key}" ]
            root_pass = "${random_string.my_wordpress_linode_root_password.result}"
            stackscript_id = "${var.stackscript_id}"
            stackscript_data = "${var.stackscript_data}"
        }
        
        resource "linode_domain" "my_wordpress_domain" {
            domain = "${var.domain}"
            soa_email = "${var.soa_email}"
            type = "master"
         }
        
        resource "linode_domain_record" "my_wordpress_domain_www_record" {
            domain_id = "${linode_domain.my_wordpress_domain.id}"
            name = "www"
            record_type = "${var.a_record}"
            target = "${linode_instance.my_wordpress_linode.ipv4[0]}"
        }
        
        resource "linode_domain_record" "my_wordpress_domain_apex_record" {
            domain_id = "${linode_domain.my_wordpress_domain.id}"
            name = ""
            record_type = "${var.a_record}"
            target = "${linode_instance.my_wordpress_linode.ipv4[0]}"
        }

        The Terraform configuration file uses an interpolation syntax to reference Terraform input variables, call Terraform’s built-in functions, and reference attributes of other resources.

        Variables and their values will be created in separate files later on in this guide. Using separate files for variable declaration allows you to avoid hard-coding values into your resources. This strategy can help you reuse, share, and version control your Terraform configurations.

      Examining the Terraform Configuration

      Let’s take a closer look at each block in the configuration file:

      1. The first stanza declares Linode as the Terraform provider that will manage the life cycle of any resources declared throughout the configuration file. The Linode provider requires your Linode APIv4 token for authentication:

        1
        2
        3
        
        provider "linode" {
            token = "${var.token}"
        }
      2. The next resource configures an SSH Key that will be uploaded to your Linode instance later in the configuration file:

        1
        2
        3
        4
        
        resource "linode_sshkey" "my_wordpress_linode_ssh_key" {
            label = "my_ssh_key"
            ssh_key = "${chomp(file("~/.ssh/id_rsa.pub"))}"
        }

        ssh_key = "${chomp(file("~/.ssh/id_rsa.pub"))}" uses Terraform’s built-in file() function to provide a local file path to the public SSH key’s location. The chomp() built-in function removes trailing new lines from the SSH key.

        Note

        If you do not already have SSH keys, follow the steps in the Create an Authentication Key-pair section of the Securing Your Server Guide.
      3. The random_string resource can be used to create a random string of 32 characters. The linode_instance resource will use it to create a root user password:

        1
        2
        3
        4
        
        resource "random_string" "my_wordpress_linode_root_password" {
            length  = 32
            special = true
        }
      4. The linode_instance resource creates a Linode with the declared configurations:

         1
         2
         3
         4
         5
         6
         7
         8
         9
        10
        
        resource "linode_instance" "my_wordpress_linode" {
            image = "${var.image}"
            label = "${var.label}"
            region = "${var.region}"
            type = "${var.type}"
            authorized_keys = [ "${linode_sshkey.my_wordpress_linode_ssh_key.ssh_key}" ]
            root_pass = "${random_string.my_wordpress_linode_root_password.result}"
            stackscript_id = "${var.stackscript_id}"
            stackscript_data = "${var.stackscript_data}"
        }
        • The authorized_keys argument uses the SSH public key provided by the linode_sshkey resource in the previous stanza. This argument expects a value of type list, so the value must be wrapped in brackets.

        • The root_pass argument is assigned to the value of the random_string resource previously declared.

        • To use an existing StackScript you must use the stackscript_id argument and provide a valid ID as a value. Every StackScript is assigned a unique ID upon creation. This guide uses the WordPress on Ubuntu 16.04 StackScript provided by Linode user hmorris. This StackScript’s ID will be assigned to a Terraform variable later in this guide.

          StackScripts support user defined data. A StackScript can use the UDF tag to create a variable whose value must be provided by the user of the script. This allows users to customize the behavior of a StackScript on a per-deployment basis. Any required UDF variable can be defined using the stackscript_data argument.

          The StackScript will be responsible for installing WordPress on your Linode, along with all other requirements, like installing and configuring the Apache Web Server, configuring the Virtual Hosts file, and installing MySQL.

        • Other arguments are given values by the Terraform variables that will be declared later in this guide.

      5. In order to complete your WordPress site’s configuration, you need to create a domain and corresponding domain records for your site. The linode_domain and linode_domain_record resources handle these configurations:

         1
         2
         3
         4
         5
         6
         7
         8
         9
        10
        11
        12
        13
        14
        15
        16
        17
        18
        19
        
        resource "linode_domain" "my_wordpress_domain" {
            domain = "${var.domain}"
            soa_email = "${var.soa_email}"
            type = "master"
         }
        
        resource "linode_domain_record" "my_wordpress_domain_www_record" {
            domain_id = "${linode_domain.my_wordpress_domain.id}"
            name = "www"
            record_type = "${var.a_record}"
            target = "${linode_instance.linode_id.ipv4[0]}"
        }
        
        resource "linode_domain_record" "my_wordpress_domain_apex_record" {
            domain_id = "${linode_domain.my_wordpress_domain.id}"
            name = ""
            record_type = "${var.a_record}"
            target = "${linode_instance.my_wordpress_linode.ipv4[0]}"
        }

        Note

        The linode_domain resource creates a domain zone for your domain.

        Each linode_domain_record resource retrieves the linode_domain resource’s ID and assigns it to that record’s domain_id argument. Each record’s target argument retrieves the IP address from the Linode instance. Every linode_instance resource exposes several attributes, including a Linode’s IPv4 address.

      Define the Input Variables

      In the terraform directory, create a file named variables.tf. This will define all the variables that were used in the main.tf file in the previous section. The values for these variables (aside from their default values) will be assigned in another file:

      ~/terraform/variables.tf
       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
      38
      39
      40
      41
      42
      43
      44
      45
      46
      
      variable "token" {
        description = "Linode API Personal Access Token"
      }
      
      variable "image" {
        description = "Image to use for Linode instance"
        default = "linode/ubuntu16.04lts"
      }
      
      variable "label" {
        description = "The Linode's label is for display purposes only."
        default = "default-linode"
      }
      
      variable "region" {
        description = "The region where your Linode will be located."
        default = "us-east"
      }
      
      variable "type" {
        description = "Your Linode's plan type."
        default = "g6-standard-1"
      }
      
      variable "stackscript_id" {
        description = "Stackscript ID"
      }
      
      variable "stackscript_data" {
        description = "Map of required StackScript UDF data."
        type = "map"
      }
      
      variable "domain" {
        description = "The domain this domain represents."
      }
      
      variable "soa_email" {
        description = "Start of Authority email address. This is required for master domains."
      }
      
      variable "a_record" {
        description = "The type of DNS record. For example, `A` records associate a domain name with an IPv4 address."
        default = "A"
      }
          

      Note

      It is recommended to include a description attribute for each input variable to help document your configuration’s usage. This will make it easier for anyone else to use this Terraform configuration.

      Every variable can contain a default value. The default value is only used if no other value is provided. You can also declare a type for each variable. If no type is provided, the variable will default to type = "string".

      The stackscript_data variable is of type map. This will allow you to provide values for as many UDF variables as your StackScript requires.

      Assign Values to the Input Variables

      Terraform allows you to assign variables in many ways. For example, you can assign a variable value via the command line when running terraform apply. In order to persist variable values, you can also create files to hold all your values.

      Note

      Terraform will automatically load any file named terraform.tfvars and use its contents to populate variables. However, you should separate out any sensitive values, like passwords and tokens, into their own file. Keep this sensitive file out of version control.

      1. Create a file named terraform.tfvars in your terraform directory to hold all non-sensitive values:

        ~/terraform/terraform.tfvars
         1
         2
         3
         4
         5
         6
         7
         8
         9
        10
        
        label = "wp-linode"
        stackscript_id = "81736"
        stackscript_data = {
          ssuser = "username"
          hostname = "wordpress"
          website = "example.com"
          dbuser = "wpuser"
        }
        domain = "example.com"
        soa_email = "user@email.com"
      2. Create a file name secrets.tfvars in your terraform directory to hold any sensitive values:

        ~/terraform/secrets.tfvars
        1
        2
        3
        4
        5
        6
        
        token = "my-linode-api4-token"
        stackscript_data = {
          sspassword = "my-secure-password"
          db_password = "another-secure-password"
          dbuser_password = "a-third-secure-password"
        }

        Note

      3. Replace the following values in your new .tfvars files:

        • token should be replaced with your own Linode account’s APIv4 token.

        • For security purposes, the StackScript will create a limited Linux user on your Linode. ssuser should be replaced with your desired username for this user.

        • sspassword, db_password, and dbuser_password should be replaced with secure passwords of your own.

        • domain should be replaced with your WordPress site’s domain address.

        • soa_email should be the email address you would like to use for your Start of Authority email address.

      Initialize, Plan, and Apply the Terraform Configuration

      Your Terraform configuration has been recorded, but you have not told Terraform to create the resources yet. To do this, you will invoke commands from Terraform’s CLI.

      Initialize

      Whenever a new provider is used in a Terraform configuration, it must be initialized before you can create resources with it. The initialization process downloads and installs the provider’s plugin and performs any other steps needed to prepare for its use.

      Navigate to your terraform directory in your terminal and run:

      terraform init
      

      You will see a message that confirms that the Linode provider plugins have been successfully initialized.

      Plan

      It can be useful to view your configuration’s execution plan before actually committing those changes to your infrastructure. Terraform includes a plan command for this purpose. Run this command from the terraform directory:

      terraform plan 
      -var-file="secrets.tfvars" 
      -var-file="terraform.tfvars"
      

      plan won’t take any actions or make any changes on your Linode account. Instead, an analysis is done to determine which actions (i.e. Linode resource creations, deletions, or modifications) are required to achieve the state described in your configuration.

      Apply

      You are now ready to create the infrastructure defined in your main.tf configuration file:

      1. Run Terraform’s apply command from the terraform directory:

        terraform apply 
        -var-file="secrets.tfvars" 
        -var-file="terraform.tfvars"
        

        Since you are using multiple variable value files, you must include each file individually using the var-file argument. You will be prompted to confirm the apply action. Type yes and press enter.

      2. Terraform will begin to create the resources you’ve defined throughout this guide. This process will take several minutes to complete. Once the infrastructure has been successfully built you will see a similar output:

          
        Apply complete! Resources: 6 added, 0 changed, 0 destroyed.
        
        
      3. Navigate to your WordPress site’s domain and verify that the site loads. You may have to wait a few minutes more after the terraform apply command returns, as the StackScript takes time to install WordPress. Additionally, it make take some time for your domain name changes to propagate:

        Install WordPress

      4. Complete the remaining WordPress configuration steps provided by the prompts.

      (Optional) Destroy the Linode Resources

      If you do not want to keep using the resources created by Terraform in this guide, run the destroy command from the terraform directory:

      terraform destroy 
      -var-file="secrets.tfvars" 
      -var-file="terraform.tfvars"
      

      Terraform will prompt you to confirm this action. Enter yes to proceed.

      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.

      Find answers, ask questions, and help others.

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



      Source link