You need a place to maintain all the content that makes up your website—HTML, javascript, CSS, images, etc. This is what we call an origin server. The Akamai edge network communicates with your origin server during client requests, grabs all of your website content, and holds it in cache for quick access to future requests. Here, you'll create compute instances ("Linodes") to act as virtual origin servers.

High availability

If you only need one origin server, why do you need multiple Linodes? This is to eliminate a single point of failure. You want your site available to your clients all the time. By adding multiple Linodes, you add redundancy through what we call High Availability. It combines load balancing and failover to better protect your site against things like hardware problems and network overload.

Linodes also eliminate the overhead that a physical redundant network would create for you. With our cost per usage model, you can scale your site as client-access requests increase. Linodes are easy to create and maintain, so you can quickly add another one to your cloud to expand redundancy.

1. Store Linode details

You'll need to gather a few identifiers before you can create a Linode.

Linode plan types

You need to review your site to get an idea of its size requirements. Then, review the available plan types to determine the one that fits your need. Finally, run this operation to get the applicable id for your selected plan type.

List Linode types

Open Recipe

Regions

Akamai cloud computing is distributed among several data centers. You need to determine the one that best fits your need. For this tutorial, all of your Linodes need to be in the same region.

Run this operation to review them and store the id for the one you want to use:

List regions

Open Recipe

2. Create the primary

Run this operation to create a Linode to serve as your primary origin server.

Create a Linode - Primary

Open Recipe

Install a LAMP stack on your primary

With your primary Linode created and booted, access it to install the, Linux, Apache2, MySQL, PHP (LAMP) stack. These are free and open source components that power many modern web applications. The individual components are designed to work together and are easy to install and use.

Follow Install and configure a LAMP stack to get set up.

Create a DNS entry

You need your domain to point to the IP address of your primary Linode. To do this, you need to update your DNS with an A record entry. For example, if you were using a domain provider like Google Domains, you would log into your DNS control panel and add a new custom record:

Set up a secure certificate

To set up high availability, one of your Linodes—your primary—will serve as a secure point of entry, using HTTPS. To accomplish this, we'll set up Certbot to create a secure, domain-validated (DV) certificate using Let's Encrypt as the certificate authority. This also enables automatic renewal for it.

Open a Terminal session and SSH into your primary:
```
ssh root@<Your primary's public IP address>
```
Type yes and press Enter to confirm.
Enter the root_password you set for this Linode.
To ensure you've got the proper version of Certbot, remove any previously installed versions:
```
sudo apt remove certbot
```
Install the Snap application and use it to install the current version of Certbot, by issuing this command:
```
sudo snap install --classic certbot
```
Configure a symbolic link to the Certbot directory using the ln command:
```
sudo ln -s /snap/bin/certbot /usr/bin/certbot
```
Request a certificate using Certbot:
```
sudo certbot --apache
```

When prompted, enter the email address the service will use to contact you with additional information:

Enter email address (used for urgent renewal and security notices)  
  (Enter 'c' to cancel): john@docsassociates.com

When prompted, enter the domain name you want protected. If you have more than one, separate each with a whitespace:

Please enter the domain name(s) you would like on your certificate (comma and/or
space separated) (Enter 'c' to cancel): docsassociates.com

📘
These points apply to any domain you enter:

It needs to be registered with an accredited registrar.

It needs to exist on your Apache2 web server. You need to follow the full process outlined in Install and configure a LAMP stack before you add a domain here.

The request is sent to Let's Encrypt to verify your domain and register the certificate. A successful completion message looks like this:

Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/docsassociates.com/fullchain.pem
Key is saved at:         /etc/letsencrypt/live/docsassociates.com/privkey.pem
This certificate expires on 2023-09-06.
These files will be updated when the certificate renews.
Certbot has set up a scheduled task to automatically renew this certificate in the background.

Deploying certificate
Successfully deployed certificate for docsassociates.com to /etc/apache2/sites-available/docsassociates.com-le-ssl.conf
Congratulations! You have successfully enabled HTTPS on https://docsassociates.com

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
If you like Certbot, please consider supporting our work by:
 * Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
 * Donating to EFF:                    https://eff.org/donate-le
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Test your secure domain

Open a browser and type in your domain. Your site should now be secure. For example, if you were using Chrome, the "Not secure" label next to your domain should be replaced by a lock icon.

Renew the certificate

A domain-validated certificate has a lifecycle of 90 days. Certbot will automatically renew your certificate before its expiration date. The only time you'll need to manually request an updated certificate is if your site's configuration file on the Apache2 server changes. In this case, you could just rerun this Certbot procedure.

If you want, you can test the automated renewal process, without affecting your current certificate.

3. Create standby #1

Run this operation to create another Linode to serve as your first standby for failover.

Create standby #1 Linode

Open Recipe

Install a LAMP stack on standby #1

High availability switches between your Linodes, to handle traffic and support failover. So, your Standby #1 Linode needs to be configured the same as your Primary. Follow the instructions in Install and configure a LAMP stack to set it up the same.

4. Create standby #2

Run this operation to create your second standby Linode:

Create standby #2 Linode

Open Recipe

Install a LAMP stack on standby #2

With your second standby Linode created and booted, install and configure a LAMP stack on it, too.

5. Add network load balancing

A NodeBalancer distributes client requests between Linodes to improve capacity, performance, and availability. Here, we'll set one up to distribute requests between the Linodes acting as your origin servers.

Get certificate information

When you set up HTTPS on the primary, an SSL certificate and its private key were generated. You'll need a few things from this certificate to continue:

The contents of these files. To add the NodeBalancer, you'll need the actual contents of both the certificate and the private key.
A SHA-1 fingerprint of the certificate. Later when you configure the Ion property to deliver your content, you'll add your Linodes and the NodeBalancer need the SHA-1 fingerprint of the certificate.

Follow these steps to get this information.

Open a Terminal session and SSH into your primary:
```
ssh root@<Your primary's public IP address>
```
Type yes and press Enter to confirm.
Enter the root_password you set for this Linode.
Navigate to the Apache2 directory that holds the certificate, replacing docassociates.com with your domain.
```
cd /etc/letsencrypt/live/docsassociates.com/
```
Open the fullchain.pem file to view its contents. This is the SSL certificate.
```
nano fullchain.pem
```

Highlight and copy the entire contents of the file.

Open a text editor and paste the content of the file. Save it as certificate.txt.
Back in the terminal, press Ctrl + X, then Y and Enter to close the .pem file.
Open the privkey.pem file. This is the private key.
```
nano privkey.pem
```

Highlight and copy the entire contents of the file.

Open a text editor and paste the content of the file. Save it as private.txt.
Back in the terminal, press Ctrl + X, then Y and Enter to close the .pem file.

At the prompt, run this command:

openssl x509 -noout -fingerprint -sha1 -inform pem -in fullchain.pem
sha1 Fingerprint=12:A3:45:67:89:BC:01:2D:EF::G3:H4:I5:67:8J:9K:0L:1M:NO:PQ

Store the SHA-1 fingerprint value, omitting all of the colons.

Set up load balancing

Run this operation to set up your NodeBalancer:

Create a NodeBalancer

Open Recipe

6. Get your site on your Linodes

🚧
This tutorial isn't intended for complex sites that integrate detailed databases or file systems. It offers an example of a basic Akamai cloud computing environment using Linodes to store a simple, secure site for delivery through the Akamai CDN.

With a LAMP stack set up on your Linodes, you essentially have a "blank canvas" you can use to house your website.

Create a new basic site

You could develop your site, directly on your primary Linode using PHP, MySQL as your database, and Apache2 as your web server. See the relevant product's documentation for details on their use.

Move your existing basic site

If you already have a simple site, you could migrate it to your primary Linode. With your Linodes deployed and LAMP installed, you'd need to:

Prepare and back up your current host.
Transfer data to your Linode.
Finish setting up your Linode.
Test your new environment. (This isn't for actual delivery, this is just to test that your site is on the Linode.)

Duplicate your site on the standbys

Once you've created a new site or migrated an existing one to your primary, you need to get it on standby #1 and standby #2. You could use rsync to copy all relevant files.

What about maintenance?

What if you need to make changes to your site? There are several ways you can set up maintenance, including detailed replication scenarios that would reflect changes from your primary directly out to your standbys. These can be pretty detailed, so they're a bit outside the scope of this document. But, the "primary + standby #1 + standby #2" model you've set up here allows for a manual method for maintenance.

Here's a rough outline of a process you could follow:

Log in to your primary.
Stop Apache2 services by running this command:
```
systemctl stop apache2
```
The service stops on your primary. Standby #1 and standby #2 are still available to the NodeBalancer.
Make the necessary updates to your website on the primary.
Login to standby #1.
Stop Apache2 services. The service stops on standby #1. Standby #2 is still available to the NodeBalancer.
Copy the changed files from the primary to standby #1, for example using rsync.
Start Apache2 services again on standby #1, by running this command:
```
systemctl start apache2
```
Login to standby #2.
Stop Apache2 services. Standby #1 is available to the NodeBalancer and all of your updates go live.
Copy the changed files from the primary to standby #2, for example using rsync.
Restart services on standby #2. It's now available to the NodeBlancer, with your updated site.
Login to your primary and restart Apache2 services. All three of your Linodes are now available to the NodeBalancer, with your updated site.

Additional resources

Here are some additional resources you might want to check out:

📘
These are third-party resources, so we can't vouch for their accuracy or timeliness.