3/4 cup (6 fl oz) warm (105-110 °F) water ( around 20 seconds in the microwave )
1/2 teaspoon sugar
1-1/8 teaspoon active dry yeast ( 1/2 package )
2 cups all-purpose flour
1/2 teaspoon salt
1/6 cup (1.3 fl oz) olive oil
For 2 large thick crust pizzas
1-1/2 cup (12 fl oz) warm (105-110 °F) water ( around 30 seconds in the microwave )
1 teaspoon sugar
2-1/4 teaspoon active dry yeast ( 1 package )
4 cups all-purpose flour
1 teaspoon salt
1/3 cup (2.7 fl oz) olive oil
Instructions
In a small bowl whisk the water, sugar, and yeast together, Let it sit for about 10 minutes or until it froths up.
In the bowl of the mixer mix together the flour, salt, olive oil, and yeast mixture with the dough hook for about 3-5 minutes or until the dough is soft and elastic. It is done when it comes clean down from the side.
To make thin crust pizza, use the dough without proofing.
For thick crust pizza, or to use it later the same day, shape the dough into a ball and put it into an oiled bowl. Also, rub the dough with oil and cover it with a foil wrap or a lid.
For thick crust pizza proof it for 30 minutes.
To use it on another day freeze the dough.
Baking
Preheat the oven to the highest temperature it can provide.
If we bake on 550 °F, the pizza is done in 8 – 10 minutes.
If your WordPress site is already hosted at another provider you may be able to save money if you manage it yourself in AWS Lightsail.
Create the WordPress Lightsail instance
To migrate your existing site to AWS Lightsail, first create a WordPress Lightsail instance. See Host WordPress in AWS Lightsail
Migrate an existing site to a Lightsail WordPress instance
Export your old WordPress site
Log into you old WordPress site
Install the All-in-One WP Migration plugin to export the existing WordPress site.
Warning: This plugin can only import sites for free under 80 MB size. If your blog export file is larger, you need to buy the “All-in-One WP Migration Unlimited” plugin for $69.
Using the plugin export the old WordPress site. In the WordPress Dashboard select Plugins, All-in-One WP Migration, Export
Click Export to to select the export location
Select File as the export location. Other methods require you to pay additional fees to the plugin creators.
The export will start automatically
When the export process completed, download the export file
Close the browser window of the old site, and do not make any more modifications in the old WordPress blog.
Import the WordPress site into the new hosting location
Import the site into the new instance
Log into your new WordPress blog with the temporary credentials described at “Log into your WordPress blog” on Host WordPress in AWS Lightsail
Update the new WordPress instance to the version of your existing blog
Install and activate the All-in-One WP Migration plugin to import the existing WordPress site into the new location.
In the Dashboard select Plugins, All-in-One WP Migration, Import
The free plugin imports maximum 80 GB export files. If your site is larger, you need to purchase the “Unlimited” plugin. The price at the time of writing is $69.
Once you installed and activated the “Unlimited” plugin, start the import again.
Select the File option
If you have selected a too small instance you get the error message There is not enough space available on the disk. Free up … GB of disk space.
In this case migrate your Lightsail instance to a larger type.
The import will display a few message boxes
Once the file has been uploaded to the instance the plugin is ready to for the modification. If you are really sure you want to overwrite the target WordPress installation, click Proceed to continue.
The actual update starts
When the update completed this message appears. If you are planing to change the domain name of the site slick the Save permalinks structure link.
Close the message with the FINISH button
Until the domain name and SSL certificate pointed to the new site
Update your “hosts” file
Permalinks in your WordPress blog contain the domain name of your site. To be able to test the new site until you point your domain to it, you can instruct your computer to use the public IP of the new site when you enter the domain name into the browser.
Open the /etc/hosts file in a text editor
Add this line and save the file:
PUBLIC_IP MY-BLOG.COM
Navigate to specific pages, not to the landing page
Open you site browsing to a specific page without using “https” in the URL to force the site to use the “http” protocol, ( MY-BLOG.COM/wp-admin/ or MY-BLOG.COM/archives/1). If you browse to the domain name only, ( MY-BLOG.COM ) the site will redirect you to the “https” protocol, the browser will constantly display warning messages, the page save and image upload will not work.
Your connection is not private
Attackers might be trying to steal your information from MY-BLOG.COM (for example, passwords, messages, or credit cards). Learn more
NET::ERR_CERT_AUTHORITY_INVALID
Once your domain has been pointed to the new LightSail instance
Update the links in the database
Replace the http://IP_ADDRESS with https://YOUR_DOMAIN
SSH into the LightSail instance as described above
Open the /opt/bitnami/wordpress/wp-config.php file cd /opt/bitnami/wordpress nano wp-config.php
Select the bitnami_wordpress database on the left side. In the wp_options table you can see the current configuration settings for ‘siteurl’ and ‘home’
On the top select the SQL tab, and enter the query below. Replace THE_OLD_URL and THE_NEW_URL with the actual values of your site. Make sure to set the correct “http” or”https” values for the old and new addresses.
set @old_url = 'http://THE_OLD_URL'; set @new_url = 'http://THE_NEW_URL'; UPDATE wp_options SET option_value = replace(option_value, @old_url, @new_url) WHERE option_name = 'home' OR option_name = 'siteurl'; UPDATE wp_posts SET post_content = replace(post_content, @old_url, @new_url); UPDATE wp_postmeta SET meta_value = replace(meta_value, @old_url, @new_url); UPDATE wp_usermeta SET meta_value = replace(meta_value, @old_url, @new_url); UPDATE wp_links SET link_url = replace(link_url, @old_url, @new_url); UPDATE wp_comments SET comment_content = replace(comment_content, @old_url, @new_url); UPDATE wp_posts SET post_content = replace(post_content, @old_url, @new_ur); UPDATE wp_links SET link_image = replace(link_image, @old_url, @new_ur); UPDATE wp_posts SET guid = replace(guid, @old_url, @new_url);
Click the Go button
Check the changes
To check the database changes execute the query select * from bitnami_wordpress.wp_options where option_name = 'siteurl' or option_name = 'home';
If you are just starting your WordPress blog, or you already have a site hosted somewhere AWS Lightsail provides a cost effective hosting solution.
To create a WordPress site in AWS Lightsail
Create a Lightsail instance
Log into your AWS account
Navigate to the Lightsail service
Set the instance location bu clicking on the Change AWS Region and Availability Zone
Select the Linux operating system (Linux has many application blueprints)
Select WordPress
Enable automatic snapshots to create daily backups
We will start with the smallest instance plan, it that serves the site well there is no reason to pay more for it.
Enter a unique name for this instance
If you want to keep track of project costs in your AWS account you can tag the instance with the project name in key-value tag
Click the Create instance button
Check the new WordPress site
You can test the WordPress site with your browser at the IP address shown on the page. For now just check if the site is running, we will log in once we created a static IP address below.
Create a static IP address
The IP address is your instance’s unique identifier on the internet. Behind the scene in the internet everything is addressed by IP addresses. Your domain name points there, and you can use it to connect to your instance. Lightsail instances have public IP addresses, but if you restart you instance it will change, so your site will be inaccessible to your visitors until you manually point your domain name to the new IP address. Statis IP addresses are free if those are connected to Lightsail instances, so there is no reason to not to create one.
On the Networking tab of your Lightsail instance click the Create static IP link
Enter a unique name for the static IP address
Click the Create button
Your site’s static IP address has been created
Log into your WordPress site
Get the temporary default password
To find the temporary default password we need to connect to the Lightsail instance
Connect to your Lightsail instance using a browser based SSH client by clicking the Connect using SSH button
or if you want to use your workstation’s terminal or any other SSH client, save the SSH key created by Lightsail in the ~/.ssh directory on your workstation. Click the Download default key link.
Execute this command in the SSH connection to get the temporary password
cat $HOME/bitnami_application_password
Log into your WordPress blog
Using your browser navigate to the login page using the public IP of your site MY_PUBLIC_IP/wp-login.php
Enter user as the user name, and the password copied from the terminal
Migrate your existing WordPress blog to the new Lightsail instance
Point your domain name to the new Lightsail instance
Once you set up your site, point your domain name to the new Lightsail instance.
Create an A (address) DNS record at your domain registrar to point your domain to the public IP address of your site.
Also create a CNAME record to redirect www. traffic to your domain.
After making DNS changes wait at least 30 minutes for the global propagation to the Lightsail instance.
Fix the permalinks
Once the domain is pointed to the WordPress site update the permalinks to include the domain name in the database entries.
Log into your WordPress blog’s dashboard
In the Settings menu select Permalinks
At the bottom click the Save Changes button
The confirmation message should appear on the top of the page
Set up a Let’s Encrypt SSL certificate
Secure the connectivity to your site with an SSL certificate. Let’s Encrypt provides free SSL certificates with auto renewal service, so you will never have to manage or pay for your SSL site certificate anymore.
If the Lightsail instance is directly exposed to the internet
If you don’t use load balancer, NGINX proxy or CDN (AWS Cloudfront) the Bitnami configuration script can create a Let’s Encrypt certificate and create a cron job for monthly automatic renewal.
Connect your Lightsail instance via an SSH connection described above
Execute the command
sudo /opt/bitnami/bncert-tool
Domains Please provide a valid space-separated list of domains for which you wish to configure your web server.
Enter the domain name of your site
The following domains were not included: www.MY-BLOG.COM. Do you want to add them? [Y/n]:
Answer Y
Enable/disable redirections Please select the redirections you wish to enable or disable on your Bitnami installation. Enable HTTP to HTTPS redirection [Y/n]:
Answer Y
Enable non-www to www redirection [Y/n]:
Answer N
Enable www to non-www redirection [y/N]:
Answer Y
The utility will list the pending changes. Do you agree to these changes? [Y/n]:
If you use a CDN network (AWS CloudFront) for content caching and delivery, you need to use the Alternative Approach to set up the Let’s Encrypt SSL certificate.
Our WordPress Lightsail instance uses the Approach A: Using system packages. configuration. (to check this, execute the command in the SSH terminal of your Lightsail instance:
test ! -f "/opt/bitnami/common/bin/openssl" && echo "Approach A: Using system packages." || echo "Approach B: Self-contained installation."
Follow the instructions below to set up the SSL certificate.
SnowRunner from Epic Games stores the game save information in a JSON file.
If you installed the game on a PC using the Epic launcher,
the game is installed at C:\Program Files\Epic Games\SnowRunner
the config file is in the %USERPROFILE%\Documents\My Games\SnowRunner\base\storage\c4c6ea08ec5f4ab8985493ea02df0122\CompleteSave.dat file.
Open the config file with a text editor, we recommend Notepad ++.
Exit the SnowRunner game
In Notepad ++ install the JSON plugin to navigate easier in the file.
Open the save file in Notepad ++
In the Plugins menu select JSON Viewer -> Format JSON
Once the modifications are done, save the file.
When you launch the game it will notify you, that the local file is newer than the sync file in the cloud. Click the Upload to cloud button to load the game with the modified file.
Add money
In the file search for the “money”: element and change the number to the amount you want to have. You can even add 999 million to last for a long time. (999999999)
To check the result of the modifications
Money
In the game press the F4 key and select the Profile tab.
Read configuration values from environment variables
Node.js natively supports the reading of environment variables.
const user_name = process.env['USER_NAME']
Automate the application build
Create the init.sh file
Create the init.sh file in the source directory and enable the execution with the command:
chmod +x init.sh
This file will contain the terminal initialization steps for the application. This example
sets the AWS_PROFILE environment variable value
AWS_PROFILE=aws1
Create the env.list file
The env.list text file contains the list of environment variables (without values) used by the application. When we run the Docker container, the –env-file option will copy those into the environment of the container.
MY_VAR1
MY_VAR2
Create the Dockerfile
The Dockerfile contains the list of instructions to build our application into a Docker container. This generic Dockerfile can build any Node.js application, as the referenced packages are listed in the “package.json” and “package-lock.json” files.
Exclude the “node_modules” and “builds” directories from the COPY . . operation
The “COPY . “. command will copy all files and directories from the “context” directory to the image. As we already placed “node_modules” into the .gitignore file, in the CI/CD pipeline it will not be available during the build, so the “npm install” command will recreate it. To be able to test the build process on our workstation, we need to ignore it during the docker build. Create the .dockerignore file in the context directory (usually in the parent of the “node_modules” directory.
WARNING: This setting will force the Docker build process to ignore the “node_modules” and “build” directories in all COPY . . commands, so if the Dockerfile uses the two step build process, explicitly copy the “node_modules” and “build” directories with the COPY –from=BUILD_IMAGE /app/node_modules ./node_modules COPY –from=BUILD_IMAGE /app/build ./build commands.
**/node_modules
**/build
Create the Makefile
In the source directory create the Makefile to automate frequently executed steps. This Makefile provides the following functionality:
make init ( the first and default option, so it is enough to type “make”)
provides instructions on how to execute the init.sh file the first time you open the terminal in this directory. (“Make” recipes execute the instructions in subprocesses, so those lines cannot update the parent environment you are calling them from. The extra dot instructs the terminal to run the init.sh script in the same process. It is same as “source” but more portable.)
make install
installs the referenced Node.js packages and saves the list in the package.json and package-lock.json files
make run
starts the application
make unittest
runs the unittest.js script
make docker-build
using the Dockerfile builds the application into a Docker container
make docker-run
runs the Docker container using the list of environment variables from the env.list file
configures the container to redirect the ingress port to the port watched by the application (first value is the container port, second value is the application port)
Add a Python-specific .gitignore file to the root of the Git repository.
Read configuration values from environment variables
Python natively supports the reading of environment variables. The os.environ.get() function reads the environment variables. This small function can intelligently report missing variables.
import os
import sys
def get_config_value(variable_name):
value = os.environ.get(variable_name, None)
if value is not None:
return value
sys.exit(f"'{variable_name}' environment variable not found")
Call it with
region_name=get_config_value("AWS_REGION")
Automate the application build
Create the init.sh file
Create the init.sh file in the source directory and enable the execution with the command:
chmod +x init.sh
This file will contain the terminal initialization steps for the application. This example
activates the Anaconda Python environment and
sets the AWS_PROFILE environment variable value
conda activate aws-worker
AWS_PROFILE=aws1
Create the env.list file
The env.list text file contains the list of environment variables (without values) used by the application. When we run the Docker container, the –env-file option will copy those into the environment of the container.
MY_VAR1
MY_VAR2
Save the list of referenced Python packages in the requirements.txt file
When you install Python packages those are available for your application. As Python is an interpreted language those packages also have to be available during runtime in the container. The pip freeze command saves the list in a text file, so the container build process can also install them.
pip freeze > requirements.txt
Create the Dockerfile
The Dockerfile contains the list of instructions to build our application into a Docker container. This generic Dockerfile can build any Python application, as the referenced Python packages are listed in the requirements.txt file. In this example our main application file is aws_worker.py
FROM python:bullseye
WORKDIR /usr/src/app
COPY requirements.txt ./
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
# -u option turns off print buffering in Python
CMD [ "python", "-u", "./aws_worker.py" ]
Create the Makefile
In the source directory create the Makefile to automate frequently executed steps. This Makefile provides the following functionality:
make init ( the first and default option, so it is enough to type “make”)
provides instructions on how to execute the init.sh file the first time you open the terminal in this directory. (“Make” recipes execute the instructions in subprocesses, so those lines cannot update the parent environment you are calling them from. The extra dot instructs the terminal to run the init.sh script in the same process. It is same as “source” but more portable.)
make run
starts the Python application
make install
installs the referenced Python packages and saves the list in the requirements.txt file
make docker-build
using the Dockerfile, builds the application into a Docker container
make docker-run
runs the Docker container using the list of environment variables from the env.list file
init:
# TO INITIALIZE THE ENVIRONMENT EXECUTE
# . ./init.sh
install:
pip install boto3
pip install requests
# Save the package list in the requirements file
pip freeze > requirements.txt
run:
python aws_worker.py
docker-build:
docker build -t aws-worker .
docker-run:
docker run -it --env-file env.list aws-worker
Containers are the future (and some of us are already there). Container technology, spearheaded by Docker, is revolutionary by allowing developers to write applications once, and run them (almost) anywhere.
Containers help developers to fully test a complete application including frontend, middle tier, and databases on their workstations, and expect the same result in the production environment.
Most applications can be migrated to containers if the runtime environment, and all application features are supported by the container architecture. Because containers are really nothing else than namespaces on the host operating system, Linux containers can natively run only on Linux host operating systems, Windows containers can natively run only on Windows hosts. Using virtual machines, it is possible to run containers on a different host operating system, but it requires an additional layer of complexity.
Twelve-Factor methodology offers guidance on multiple aspects of the application design, development, and deployment. During our migration process we will extensively use the third, “Configuration” factor. This recommends to get configuration values from environment variables, so the same code can be deployed to any environment without changes. This guarantees code parity between test and production environments to reduce the risk of failures during the promotion to a higher environment.
Using environment variables our application can read them the same way regardless where it runs.
Store configuration values in environment variables
On our workstation we can set environment variables
manually in the terminal (not recommended),
in the ~/.bashrc file ( on Linux )
in the “Environment Variables” section of the computer properties ( on Windows )
in a file called from the ~/.bashrc file ( on Linux )
with an auto executed script reading values from Vault or any other secure secret storage ,and saving them in environment variables.
Automate everything
Automation allows us to build, test and deploy our application quickly and frequently without manual intervention. This avoids human errors during the CI/CD process and produces the same result every time we run the CI/CD pipeline.
These are language agnostic recommendations, on the language specific pages listed below we will revisit them in more detail.
Create the init.sh file
Create the init.sh file in the source directory and enable the execution with the command:
chmod +x init.sh
This file will contain the terminal initialization steps for the application. This example
sets the AWS_PROFILE environment variable value.
AWS_PROFILE=aws1
Create the env.list file
The env.list text file contains the list of environment variables (without values) used by the application. When we run the Docker container, the –env-file option will copy those into the environment of the container.
MY_VAR1
MY_VAR2
Create a Makefile
In the source directory create the Makefile to automate frequently executed steps. This Makefile provides the following functionality:
make init ( the first and default option, so it is enough to type “make”)
provides instructions on how to execute the init.sh file the first time you open the terminal in this directory. (“Make” recipes execute the instructions in subprocesses, so those lines cannot update the parent environment you are calling them from. The extra dot instructs the terminal to run the init.sh script in the same process. It is same as “source” but more portable.)
make docker-build
using the Dockerfile builds the application into a Docker container
make docker-run
runs the Docker container using the list of environment variables from the env.list file
init:
# TO INITIALIZE THE ENVIRONMENT EXECUTE
# . ./init.sh
docker-build:
docker build -t MY_APP .
docker-run:
docker run -it --env-file env.list MY_APP
