Working from wp-config-sample.php
The wordpress/wp-config-sample.php will serve as the start of our wp-config.php that we’re copying in. From the root we’ll copy this config file into the wordpress directory that we’ll be zipping up.
The following diff gives a short summary of the changes being made from the base sample:
20a21,28
> /** Detect if SSL is used. This required since we need to be able to
> terminate SSL either on CloudFront or the ELB */
> if ($_SERVER['HTTP_CLOUDFRONT_FORWARDED_PROTO'] == 'https' OR
> $_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https')
> {
> $_SERVER['HTTPS'] = 'on';
> }
>
23c31
< define( 'DB_NAME', 'database_name_here' );
---
> define( 'DB_NAME', $_SERVER["RDS_DB_NAME"] );
26c34
< define( 'DB_USER', 'username_here' );
---
> define( 'DB_USER', $_SERVER["RDS_USERNAME"] );
29c37
< define( 'DB_PASSWORD', 'password_here' );
---
> define( 'DB_PASSWORD', $_SERVER["RDS_PASSWORD"] );
32c40
< define( 'DB_HOST', 'localhost' );
---
> define( 'DB_HOST', $_SERVER["RDS_HOSTNAME"] );
49,56c57,70
< define( 'AUTH_KEY', 'put your unique phrase here' );
< define( 'SECURE_AUTH_KEY', 'put your unique phrase here' );
< define( 'LOGGED_IN_KEY', 'put your unique phrase here' );
< define( 'NONCE_KEY', 'put your unique phrase here' );
< define( 'AUTH_SALT', 'put your unique phrase here' );
< define( 'SECURE_AUTH_SALT', 'put your unique phrase here' );
< define( 'LOGGED_IN_SALT', 'put your unique phrase here' );
< define( 'NONCE_SALT', 'put your unique phrase here' );
---
> define( 'AUTH_KEY', $_SERVER["SECRET_AUTH_KEY"] );
> define( 'SECURE_AUTH_KEY', $_SERVER["SECRET_SECURE_AUTH_KEY"] );
> define( 'LOGGED_IN_KEY', $_SERVER["SECRET_LOGGED_IN_KEY"] );
> define( 'NONCE_KEY', $_SERVER["SECRET_NONCE_KEY"] );
> define( 'AUTH_SALT', $_SERVER["SECRET_AUTH_SALT"] );
> define( 'SECURE_AUTH_SALT', $_SERVER["SECRET_SECURE_AUTH_SALT"] );
> define( 'LOGGED_IN_SALT', $_SERVER["SECRET_LOGGED_IN_SALT"] );
> define( 'NONCE_SALT', $_SERVER["SECRET_NONCE_SALT"] );
>
> define('WP_HOME', $_SERVER['WP_HOME']);
> define('WP_SITEURL', $_SERVER['WP_SITEURL']);
>
> $site_name = $_SERVER['SITE_NAME'];
> // define('WP_CONTENT_DIR', "/mnt/efs/$site_name/wp-content"); // TODO Uncomment after efs deployedEnabling SSL
20a21,28
> /** Detect if SSL is used. This required since we need to be able to
> terminate SSL either on CloudFront or the ELB */
> if ($_SERVER['HTTP_CLOUDFRONT_FORWARDED_PROTO'] == 'https' OR
> $_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https')
> {
> $_SERVER['HTTPS'] = 'on';
> }
> Now that we’re having to establish the wordpress wp-config, first thing we gotta do is make sure that we even support ssl at all. You’ll notice if you look at the GitHub copy of the aforementioned wp-config that I’ve made some modifications. And so we’re terminating ssl. Even though in a single instance configuration technically our EC2 instance will have an elastic ip assigned, it’s still important that when the site scales that both CloudFront and Elastic Load Balancing is supported. There are many different configurations you can do to achieve this.
Environment Variables
23c31
< define( 'DB_NAME', 'database_name_here' );
---
> define( 'DB_NAME', $_SERVER["RDS_DB_NAME"] );
26c34
< define( 'DB_USER', 'username_here' );
---
> define( 'DB_USER', $_SERVER["RDS_USERNAME"] );
29c37
< define( 'DB_PASSWORD', 'password_here' );
---
> define( 'DB_PASSWORD', $_SERVER["RDS_PASSWORD"] );
32c40
< define( 'DB_HOST', 'localhost' );
---
> define( 'DB_HOST', $_SERVER["RDS_HOSTNAME"] );
49,56c57,70
< define( 'AUTH_KEY', 'put your unique phrase here' );
< define( 'SECURE_AUTH_KEY', 'put your unique phrase here' );
< define( 'LOGGED_IN_KEY', 'put your unique phrase here' );
< define( 'NONCE_KEY', 'put your unique phrase here' );
< define( 'AUTH_SALT', 'put your unique phrase here' );
< define( 'SECURE_AUTH_SALT', 'put your unique phrase here' );
< define( 'LOGGED_IN_SALT', 'put your unique phrase here' );
< define( 'NONCE_SALT', 'put your unique phrase here' );
---
> define( 'AUTH_KEY', $_SERVER["SECRET_AUTH_KEY"] );
> define( 'SECURE_AUTH_KEY', $_SERVER["SECRET_SECURE_AUTH_KEY"] );
> define( 'LOGGED_IN_KEY', $_SERVER["SECRET_LOGGED_IN_KEY"] );
> define( 'NONCE_KEY', $_SERVER["SECRET_NONCE_KEY"] );
> define( 'AUTH_SALT', $_SERVER["SECRET_AUTH_SALT"] );
> define( 'SECURE_AUTH_SALT', $_SERVER["SECRET_SECURE_AUTH_SALT"] );
> define( 'LOGGED_IN_SALT', $_SERVER["SECRET_LOGGED_IN_SALT"] );
> define( 'NONCE_SALT', $_SERVER["SECRET_NONCE_SALT"] );
>
> define('WP_HOME', $_SERVER['WP_HOME']);
> define('WP_SITEURL', $_SERVER['WP_SITEURL']);
>
> $site_name = $_SERVER['SITE_NAME'];
> // define('WP_CONTENT_DIR', "/mnt/efs/$site_name/wp-content"); // TODO Uncomment after efs deployedYou see in the sample wp-config that we’ve got a bunch of hard coded samples. We need to be able to take these in from Elasticbeanstalk. We’ve already scripted some of the environment variables. So what we can do is bring in all of those. These salts look really familiar. We went through all the effort of automating these from the wordpress API, so now we’re going to go ahead and pull those in.
Having control of the WP_HOME from the console is nice. We’re trying to make this as easy and hands off as possible. Over the years I’ve had to set these and so I’ve just made it really super convenient to do so from the console. So I don’t have to log into those EC2 instances being managed by Elasticbeanstalk on my behalf.
We’re not going to worry about the WP_CONTENT_DIR just yet. When we move off a single EC2 instance to where we have multiple EC2 instances behind a load balancer, for when we scale up the site, we’ll have to make sure that it’s mounted in a place where all those ec2 instances can reach the files so that way we can horizontally scale; add as many servers as we need to burst to handle the additional load. Seems a bit crazy to think about that here, when designing these Elasticbeanstalk source bundles, it does become important, because when you try to switch out of a single instance configuration into a load balanced application, this is one area where we can actually support horizontal scaling.
What we can do is stub in that define here. Then we’ll revisit it in a later section. I know you’ve had to look at a lot of this on faith. We’re going to test this deployment. This efs mount that I’m defining here doesn’t exist yet, but, it will in a future section. So what we’ll do is just comment that out for now, and give ourselves a TODO.
Next Steps
So in the next section we’ll focus on deploying the source bundles so we can actually test the work that we’ve done here.
Like in many other deployments, sometimes it’s just a good idea to jump right in, and see what happens. Which is why I’ve stubbed this in, just to give us just enough to establish a new Elasticbeanstalk deployment in an easily repeatable way, especially as the number of steps continues to increase with the number of features we’ll continue to add over time.