I’ve recently been updating the technical infrastructure for this blog. My aim has been to use AWS as much as possible, partly for convenience and partly for education. Having recently migrated the blog from EC2 to Elastic Beanstalk (EB), my latest project has been to refactor the blog’s build-and-deployment workflow to use AWS, specifically some of the services within the CodeSuite toolset. I’ll be writing some posts over the coming weeks to describe what this project involved.

Given that the new workflow ended up being rather more complicated than the old one (which was based on GitHub Actions and EB CLI), I’ll begin by summarizing the refactored version’s design.

Design summary

Following is the basic sequence of events I outlined for the new workflow:

1. I push a commit to my GitHub repository
2. CodeBuild pulls the code from GitHub and initiates a build
3. CodeBuild logs in to ECR
4. CodeBuild builds the Docker images, tags them and pushes them to ECR
5. CodeBuild builds a source bundle for EB and pushes it to S3
6. CodePipeline pulls the source bundle from S3 and deploys it to EB
7. EB pulls the Docker images from ECR and starts the application

Or, to express this as a diagram…

For anyone who is not familiar with the AWS services involved in this workflow, following are some brief explanations of these:

• CodeBuild is a continuous-integration (CI) service that orchestrates the build phase of the build-and-deployment process.
• CodePipeline is a continuous-deployment (CD) service that orchestrates the overall build-and-deployment process.
• ECR is a container registry that provides remote storage for Docker containers.
• S3 is a general-purpose object storage service.
• EB is a Platform-as-a-Service (PaaS) product that facilitates the deployment of Web applications built on different platforms, e.g., Docker, Node.js, etc.

I’ll now go into how I implemented this high-level design, starting with how I integrated my GitHub repository with AWS, given that pushing a commit to the repository needs to trigger a run on CodeBuild.

Integrating GitHub and AWS

To integrate my GitHub repository with AWS, I installed the “AWS Connector for GitHub” application to my GitHub account–applications can be installed to a GitHub account via the account’s Settings.

Once the application is installed, it’s possible to authorize it to access either all or only select repositories within an account.

Via the AWS Developer Tools Settings, I then created a connection resource. For this I just needed to choose GitHub as the Provider for the connection; AWS then allowed me to select my specific “AWS Connector for GitHub” installation. Saving the connection resulted in it being available on the Connections page of AWS Developer Tools.

With the connection between GitHub and AWS established, I was now in a position to create the CodeBuild project, the central component of the overall pipeline.

Creating the CodeBuild project

Creating a CodeBuild project generally involves two main steps:

1. Configuring a CodeBuild project via AWS
2. Adding a buildspec to a repository for the CodeBuild project to read from

For anyone who is not familiar, a CodeBuild project is a configurable job that focuses on the build stage of a CI/CD pipeline, while a buildspec is a YAML file that defines specific instructions for a CodeBuild project.

As I mentioned in the design summary, the two main side effects of my build stage are (1) for Docker images to be pushed to ECR and (2) for an EB source bundle to be uploaded to S3. I’ll address these specifics in a subsequent post; for the rest of this one I’ll focus on the rudiments of adding the buildspec and configuring the CodeBuild project.

Adding the buildspec

To keep things as simple as possible, then, following is an example of a skeletal buildspec:

version: 0.2
phases:
  build:
    commands:
      - echo Hello, world!
artifacts:
  files:
    - 'test.txt'

In this example, “version” specifies the latest buildspec version, while “phases” specifies the commands CodeBuild should run during each phase of the build. For demo purposes I am using a single phase (“build”) and a single command (“echo Hello, world!”). Under “artifacts”, I am also specifying a single file (“test.txt”) that CodeBuild should consider to be an artifact of the build process.

Like I say, meat will be added to the bones of this buildspec in a subsequent post. For now, though, I’ll move on to discussing how to configure the CodeBuild project to read from the buildspec.

Configuring the CodeBuild project

CodeBuild projects are highly configurable. For the purposes of my buildspec, though, there were relatively few settings I needed to change from their defaults–these are itemized below. (Note the important prerequisite of creating an S3 bucket in which to store the build artifact.)

• Project configuration
  • Project name: <PROJECT_NAME>
  • Project type: Default project
• Source
  • Source 1 – Primary
    • Source provider: GitHub
    • Repository: Repository in my GitHub account
    • Repository: <REPOSITORY>
    • Source version: <BRANCH>
• Buildspec
  • Build specifications
    • Use a buildspec file: true
• Artifacts
  • Artifact 1 – Primary
    • Type: Amazon S3
    • Bucket name: <BUCKET_NAME>
    • Artifacts packaging: Zip

With the CodeBuild project thus configured, pushing a commit to my GitHub repository on the relevant branch successfully kicked off a CodeBuild run. Runs are logged in the CodeBuild project’s Build History.

As designed, the run resulted in a compressed version of the build artifact being uploaded to the configured S3 bucket.

Conclusion

In this post I’ve addressed the first two steps of the design summary I provide above: pushing a commit to GitHub and initiating a CodeBuild run. In a subsequent post I’ll aim to address the remaining CodeBuild-related steps of the design summary: logging into ECR; building and tagging the Docker images, and pushing them to ECR; and pushing the EB source bundle to S3.

SSL offloading is an approach to handling secure Web traffic in which the computational burden of processing encrypted requests is allocated (or “offloaded”) to a specific component within an application’s environment.

The approach can improve performance as it allows application servers to serve unencrypted requests, which are computationally less expensive than encrypted ones. It can also reduce maintenance overhead as it requires certificates to be installed only on the component that is handling encrypted requests.

The approach obviously cannot be used in environments that require end-to-end encryption; in environments that do not have this requirement, however, it can be a useful technique to employ.

In this post I will describe how SSL offloading was implemented for this blog, a WordPress application that is deployed to AWS Elastic Beanstalk (EB). In so doing I make the following assumptions:

• The use of .ebextensions files to configure the EB environment
• The use of the EB CLI to create the environment
• The use of Apache HTTP Server as the WordPress application’s Web server

With these caveats out of the way, the first step toward implementing SSL offloading for this blog was to ensure the EB environment was instantiated with a load balancer, given that the load balancer is the component that will be handling encrypted requests.

Establishing the load balancer

In order for the EB environment to be instantiated with a load balancer, it was necessary to configure the environment for autoscaling. This is because, unlike single-instance environments, autoscaled environments require a load balancer in order to distribute traffic among EC2 instances. Following is the .ebextensions file that was used to ensure the load balancer was created:

option_settings:
  aws:autoscaling:launchconfiguration:
    InstanceType: {{InstanceType}}
  aws:autoscaling:asg:
    MinSize: {{MinSize}}
    MaxSize: {{MaxSize}}

The config specifies the type of EC2 instance (e.g., t3.small) autoscaling should launch within the target group, as well as the minimum and maximum number of instances that should be allowed within the group. (MinSize and MaxSize can both be set to 1 if a single instance is desired.)

With autoscaling thus configured, the next step toward implementing SSL offloading for this blog was to configure the load balancer itself.

Configuring the load balancer

Given that the load balancer needs to handle encrypted requests and that its default listener doesn’t handle such requests, it was necessary to create a new listener on the load balancer specifically for this purpose. Following is the .ebextensions file that was used to establish this listener:

Resources:
  HttpsListener:
    Type: AWS::ElasticLoadBalancingV2::Listener
    Properties:
      LoadBalancerArn:
        Ref: AWSEBV2LoadBalancer
      Protocol: HTTPS
      Port: 443
      DefaultActions:
        - Type: forward
          TargetGroupArn:
            Ref: AWSEBV2LoadBalancerTargetGroup
      Certificates:
        - CertificateArn: {{CertificateArn}}
      SslPolicy: {{SslPolicy}}

The config specifies the type of resource to create (AWS::ElasticLoadBalancingV2::Listener) and the properties it should be created with. Some notes on the specific properties:

• LoadBalancerArn: References the load balancer by its logical name
• Protocol: Specifies that the listener should listen for HTTPS requests
• Port: Specifies that the listener should listen on port 443
• DefaultActions: Specifies that requests should be forwarded to the load balancer’s associated target group
• Certificates: References the SSL certificate (in this case stored in AWS Certificate Manager) that should be used to process requests
• SslPolicy: Specifies the SSL policy that should be used to enforce standards for the requests

With the load balancer thus configured, the next step toward implementing SSL for this blog was to configure the load balancer’s security group.

Configuring the load balancer’s security group

Given that the load balancer needs to process incoming requests on port 443 and that its security group doesn’t allow such requests by default, it was necessary to create an inbound rule on the security group for this purpose. Following is the .ebextensions file that was used to establish this inbound rule:

Resources:
  HttpsIngressRule:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      GroupId:
        Ref: AWSEBLoadBalancerSecurityGroup
      IpProtocol: tcp
      FromPort: 443
      ToPort: 443
      CidrIp: 0.0.0.0/0

The config specifies the type of resource to create (AWS::EC2::SecurityGroupIngress) and the properties it should be created with. Some notes on the specific properties:

• GroupId: References the security group for the load balancer by its logical name
• IpProtocol: Specifies that the rule applies to TCP traffic
• FromPort: Specifies the lowest port number the rule should apply to
• ToPort: Specifies the highest port number the rule should apply to
• CidrIp: Specifies that the rule should allow traffic from the outside world

(Note that FromPort and ToPort have the same value; this results in the rule limiting traffic to port 443.)

With the security group thus configured, the EB environment was now ready to be created. Running eb create against the .ebextensions files described above created and configured a load balancer, and configured the load balancer’s security group.

With the EB requirements addressed, the only remaining step in implementing SSL offloading for this blog was to configure the WordPress application’s Web server to be able to operate in the context of an SSL-offloaded environment.

Configuring the Web server

The Web server used by the WordPress installation for this blog is Apache HTTP Server (Apache). Given that encrypted requests are being offloaded to EB, Apache is free to serve unencrypted requests, which as you’ll recall is one of the benefits of SSL offloading.

In order to resolve URLs correctly, however, WordPress needs to know that a request was originally encrypted, i.e., was sent over HTTPS. As such it was necessary to configure Apache to make WordPress “context-aware.” This was done via the following customization to the Apache conf file:

<VirtualHost *:80>
  ...
  <IfModule mod_setenvif.c>
    SetEnvIf X-Forwarded-Proto "^https$" HTTPS
  </IfModule>
  ...
</VirtualHost>

The customization sets an environment variable (HTTPS) if Apache detects that a request was originally sent over HTTPS–internally WordPress reads from this variable when determining the protocol for URLs. A check is made to ensure Apache’s setenvif module is enabled. If so, the SetEnvIf directive enables the environment variable if the request has an “X-Forwarded-Proto” header with a value matching the supplied regular expression–“X-Forwarded-Proto” is an HTTP header that is sent along with requests from the EB load balancer to Apache. Note that Apache is configured to run on port 80 (VirtualHost *:80).

With Apache thus configured, SSL offloading was fully implemented for this blog.

Conclusion

While I wasn’t aware of SSL offloading as an approach prior to migrating this blog to EB, finding out about the approach and then implementing it turned out to be an added benefit of the migration, both in terms of simplifying the configuration for the blog’s development and production environments, and in terms of heightening my own awareness of the architecture that underpins an EB environment.

This blog is hosted on an AWS EC2 instance; the code for it is stored in a GitHub repository. In order to update the code on the EC2 instance I previously would manually connect to the EC2 instance via SSH client, pull the code from the GitHub repository and then execute the necessary command to redeploy the code. While this got the job done, it always felt rather clunky and tedious. Last week I finally got around to automating the process. In today’s post I’ll be discussing the solution I came up with.

Essentially my approach involves integrating GitHub Actions with AWS Systems Manager to deploy the code on the EC2 instance on a push of the code to a branch of the GitHub repository. The GitHub Actions workflow consists of two steps, which are as follows:

1. Configuring the AWS credentials
2. Executing the deployment

The rest of this post will go into a bit more detail about each of these steps.

I’ll start by stubbing out the GitHub Actions workflow I’m using:

name: Deploy to EC2

on:
  push:
    branches:
      - master

jobs:
  deploy:
    runs-on: ubuntu-latest

    steps:
    - name: Configure AWS credentials
    ...
    - name: Execute deployment script on EC2 instance
    ...

- name: Configure AWS credentials
  uses: aws-actions/configure-aws-credentials@v1
  with:
    aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
    aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
    aws-region: us-east-1

1. document-name – The name of the Amazon Web Services Systems Manager document (SSM document) to run.
2. targets – An array of search criteria that targets managed nodes using a key-value combination that you specify.
3. parameters – The required and optional parameters specified in the document being run.
4. timeout-seconds – If this time is reached and the command hasn’t already started running, it won’t run.

For document-name I specify “AWS-RunShellScript”–this is a shared resource available via Systems Manager Documents that enables Systems Manager to run a shell script.

For targets, I specify “instanceids” as “Key” and the instance ID of my EC2 instance as “Values.”

For parameters, I specify a string in the following form (where <command> represents a specific instruction to provide to the EC2 instance):

'commands=[
  "<command>"
]'

Finally for timeout-seconds, I specify a value of 600 (10 minutes).

With these things in place the complete step ended up as follows:

- name: Execute deployment script on EC2 instance
  run: |
    aws ssm send-command \
      --document-name "AWS-RunShellScript" \
      --targets "Key=instanceids,Values=${{ secrets.EC2_INSTANCE_ID }}" \
      --parameters 'commands=[
        "<command>"
      ]' \
      --timeout-seconds 600

(Similar to before I store the EC2 instance’s ID as a secret in the repo’s security settings so as not to expose it publicly.)

So this is pretty much it. A push of the code to the master branch of the repo now results in the code being deployed automatically to the EC2 instance via the GitHub Action. Handily the results of the execution are available in Command History under Systems Manager > Run Command.

Clicking into the detail of a command exposes further info such as output and error logging, plus the ability to re-run the command from Systems Manager itself.

All in all this was a fun little project that took a day or two of tinkering to get working.

This blog is currently hosted on AWS EC2. Until recently I would always connect to my EC2 instance via SSH client. An alternative approach I learned of recently is to connect via Session Manager, a feature of AWS Systems Manager. A main benefit of Session Manager is that it removes the need to open inbound ports to the instance or manage SSH keys as Session Manager handles these security details for you.

Using Session Manager involves a few prerequisites, which can be reduced to the following three-step process:

1. Provisioning the EC2 instance with the SSM^* agent
2. Provisioning the EC2 instance with an IAM role
3. Restarting the SSM agent to detect the IAM role

^* Simple Systems Manager

Detailed instructions follow. Note that these instructions are specific to Ubuntu 14.04, which I appreciate is quite outdated at time of writing. Steps 1 and 3 require you to be connected to an EC2 instance (for example via SSH client). Step 2 requires you to be logged in to the AWS Management Console.

Provisioning the EC2 instance with the SSM agent

The first main step toward connecting to an EC2 instance via Session Manager is to install the SSM agent on the EC2 instance. For my OS this involved running the following commands against the instance:

// Update the OS package index
sudo apt-get update

// Download the SSM agent package
wget https://s3.amazonaws.com/amazon-ssm-us-east-1/latest/debian_amd64/amazon-ssm-agent.deb

// Install the SSM agent package
sudo dpkg -i amazon-ssm-agent.deb

// Start the SSM agent
sudo start amazon-ssm-agent

// Verify the SSM agent status
sudo status amazon-ssm-agent

This last command should produce output like the following:

amazon-ssm-agent start/running, process 4180

Provisioning the EC2 instance with an IAM role

The second main step toward connecting to an EC2 instance via Session Manager is to provision the EC2 instance with an IAM role granting permission to Session Manager to connect to the instance. This step involves (1) creating the IAM role and (2) attaching the role to the instance.

Still in the AWS Management Console go to EC2. From the left nav click Instances and from the Instances pane select the relevant instance. From the Security submenu of the Actions menu select “Modify IAM Role.” From the “IAM role” menu select the role you created in the previous step. Then click “Update IAM role.”

From the Instances pane select the relevant instance again (assuming it’s not already selected). Verify that the role is attached to the instance–it should be listed under the “IAM Role” heading in the Details tab of the Instances pane.

Still in the Instances pane and with the relevant instance still selected, click Connect. From the “Connect to instance” page select the “Session Manager” tab. You should be presented with a page that resembles the following screenshot:

Note (a) the disabled Connect button and (b) the warning about the instance not being connected to Session Manager–both would be expected at this stage since it’s necessary to restart the SSM agent in order for the instance to detect the updated IAM role.

Restarting the SSM agent to detect the IAM role

The last main step, then, toward connecting to an EC2 instance via Session Manager is to restart the SSM agent in order for EC2 to detect the updated IAM role. For my OS this involved running the following command against the instance:

sudo restart amazon-ssm-agent

As I prepare to start a new job on Monday, the first new job I’ll have started for more than seven years (God, please don’t let me get beaten up behind the bike sheds on my first day!), I’ve been making an effort to organize the detritus of my online life.

Loyal readers of this blog—if indeed such emotionally troubled individuals are currently blessed with reading privileges in the various jailhouses and detention centers they occupy—will recall my inaugural post about a password manager application I’ve been using called 1Password, made by a Canadian software company called AgileBits. As the name “1Password” suggests, the (IMO truly magnificent) app allows you to create one strong, memorable password that gives you access to a database into which you can enter all your other Web site log-in credentials, the passwords for which can be as strong and unmemorable as you wish. As if this functionality were not useful enough, the app also gives you the ability to log in to your favorite Web sites automatically, which in effect frees you from the very 21st-century hassle of entering slight variants of the same credentials into Web-based log-in forms time after tedious time.

In more recent days I’ve also been exploring some of 1Password’s additional capabilities, such as the way it allows you to store personal information (e.g., bank account, credit card and driver’s license information), in what the app calls “Wallet items.” Given my increasing reliance on the Web for performing financial and commercial transactions, having this information stored centrally in such a fashion has been proving pretty useful. Now, for instance, I don’t have to search my coat pockets for my actual wallet whenever I need my credit card for Turnov’s Small and Short men’s shop, a card whose number, expiry date and security code have escaped—or indeed have never been stored in—my memory. This liberating upshot is all the more satisfying given the numerous types of coat I’ve had to wear this winter here in the environs of Alexandria, Va., where the weather has been changing as much as a chameleon with multiple personality disorder in a dressing room.

To turn to, or at least look askance at, the subject of email organization, I’ve also been striving to exert a measure of control over my hitherto untamed Gmail inbox. This effort has necessitated creating a large number of labels and a not small number of filters. I now have as many as 17 top-level labels for my received mail, each of which has sub-labels that allow for more specific content characterization. Without wishing to give you too much insight into my personal life, here are the top-level labels I’ve settled on to-date:

• Banking
• Car (“Pollution-Spewing Heap of Rust” would be more accurate)
• Credit Cards
• Entertainment
• Health & Fitness (just the one email under this label so far)
• Home
• Insurance
• Investments
• Local Government
• Meetups (nice to get out of Chez Smith from time to time)
• Personal
• Personal Finance
• Shopping
• Taxes (would “Death and Taxes” last longer?)
• Travel & Transit
• Web Services
• Work

Readers who take their mobility for granted might argue that going to such organizational lengths as these evinces a certain anal-retentiveness in me. And while I wouldn’t render them entirely unable to walk for arguing this way, I would suggest that if the feeling one gets from having an organized inbox is preferable to the feeling one gets from having a disorganized inbox, then the better feeling alone justifies the effort one has made in organizing it. So there, with highly polished brass knobs on!

In conclusion, I think “personal information architecture” projects like these will increase in importance as our weird, wired world becomes more data-centric and IT-reliant. Instead of finishing with a supposition, however, I’ll finish with a question: Do you—my loyal, incarcerated readers—attempt to organize your inboxes? Or do you allow them to grow untamed, like the tangled hair of an aging hippie?

If I were to suggest to you that global warming, population growth and password management were among the 21st century’s greatest problems, you would of course be perfectly justified in observing that only two of these topics deserve such weighty description: As we all know, the dangers to mankind of global warming are vastly overstated and in fact may be apocryphal.

Before any partisan bickering that my previous assertion might have provoked descends into outright violence, allow me to raise my voice above the din for a moment to plead, “I was only joking!” Compared to the mountainous environmental and demographic issues already identified, the personal tech problem of managing one’s Web site login credentials seems molehill-like indeed. Modest though its heights may be, however, they still must be scaled. It pleases me to report that with the aid of a trusty Sherpa I have in recent days been able to scale them!

Playing Tenzing Norgay to my Edmund Hillary is 1Password, a desktop password-management application from the privately held Canadian company AgileBits. According to the manufacturer’s Web site, versions for Mac, Windows, iPhone, iPad and Android are available. This discussion concerns 1Password 3 for Mac, which requires OS X Snow Leopard and higher. (Tiger and Leopard users, the manufacturer mollifies, can use 1Password 2 and sync their data with Snow Leopard or Lion.) A single-user license cost me $49.99 from the manufacturer’s Web site.

The central idea of 1Password is straightforward:

1. You create a single, master password to the app.
2. You enter your login credentials for any given Web site into the app’s database.
3. The app, upon entry of the correct master password, gives you access to all the credentials you’ve entered.

The upshot is that you only have to remember one password (hence the name, duh!) in order to have access to your login credentials for any given site. This comes in especially handy if, like me, you have accumulated several variations of usernames and passwords since Web time (Berners-Lee time?) began. I, for instance, have amassed as many as 20 unique usernames!

Having only one password to remember also enables you to practice good Web security and create a strong, unique password for each of your stored sites. 1Password conveniently includes a random-password generator for the purpose. The generator features several password-customization options, including the number of characters the password should contain, the number of digits or special characters it should contain, whether it can contain the same character more than once, and even whether it should be pronounceable!

1Password also includes a delightfully time-saving auto-login feature, which alone justifies the app’s license fee IMHO. Double-click the name of any given Web site from within the app to be instantly directed to and logged into that site. For even quicker, one-click access, install the app’s Web browser extension, in which you can also perform other common tasks, such as data entry.

What happens if a Web site requires you to enter your username on one screen and your password on another? Simply create two records in the database: one for the username screen and one for the password screen, taking care to name each record meaningfully. Then simply choose the relevant record from the app or browser extension.

Do you use a Mac at home and a PC at work? Combine 1Password with the built-in 1PasswordAnywhere and the file-hosting service Dropbox for access to your login credentials from wherever you happen to be doing your Web browsing. In addition to login credentials, 1Password also promises the ability to store other types of sensitive information, such as software licenses, free-form text, and personal and financial information. I’m looking forward to trying these features out in the coming days.

In the meantime you can color me impressed. Although there may be freely available alternatives that perform just as well, I feel as though my money has been well-spent on 1Password. A piece of software that saves me time and makes me feel a bit more organized seems to me invaluable in this time-crunched era of ours. If these do not strike you as reasons enough to reach for the summit of your own password management mountain (or molehill), then why not turn to the sentiments of another celebrated Everest assaulter: Do it because it’s there!