I started with BASIC on a Sinclair ZX81. Then, I moved on to an Acorn Electron. I later looked on with envy at a neighbour. This neighbour was a few years older than me. They had all the exciting kit — Atari machines and then an Amiga. I eventually bought an Amiga A500 Plus with my first pay cheque, later an A1200, and that’s where I first started experimenting seriously with C and C++.

After a break, I returned to university in the late 1990s to formally study Computer Science.

I’m now fifty, and while I still care deeply about code quality, I’ve learned that some of the “religious wars” of our industry are better approached with perspective than pitchforks. The tabs vs spaces debate is a perfect example.

This isn’t a rant. It’s a preference — informed by a lot of years reading, writing, reviewing, and maintaining other people’s code.

What a tab actually is (and isn’t)

A tab character does not represent a fixed amount of whitespace.

A tab is an alignment character. When rendered, it moves the cursor to the next tab stop. Where that tab stop lies depends entirely on editor configuration. One developer might use tab stops of 2 spaces, another 4, another 8 — all perfectly valid choices.

This flexibility is intentional, and it’s also where most problems start.

Legitimate reasons to use tabs

There are good, well-established reasons to use tabs, and it’s worth stating that clearly:

• Accessibility: Tabs allow developers to adjust indentation width to suit eyesight or personal preference without changing the file.
• Established conventions: Some ecosystems explicitly require tabs (Makefiles being the canonical example).
• Column alignment: Tabs can be genuinely useful for aligning tabular data.
• Long-lived codebases: Many large projects standardised on tabs decades ago, and consistency matters more than re-litigating old decisions.

Using tabs in these contexts is not wrong, careless, or outdated.

In collaborative environments, tabs can introduce subtle problems when:

• Contributors use different tab stop widths
• Indentation is done manually rather than via editor automation
• Tabs are used inconsistently or mixed with spaces

The result is familiar: code that looks neatly structured in one editor becomes misaligned and hard to read in another. This isn’t because tabs are “bad” — it’s because their visual meaning is contextual.

When indentation carries semantic or cognitive weight — as it does in Python, YAML, or deeply nested logic — that variability becomes a real source of distraction and, occasionally, error.

Why I still prefer spaces

Personally, I prefer spaces for indentation.

Not because tabs are invalid, but because spaces optimise for predictability:

• A space is always exactly one column wide.
• What you see in your editor is what everyone else sees.
• Structure and alignment are unambiguous.
• Diffs are cleaner and easier to review.
• Accidental misalignment is harder to introduce.

In practice, spaces achieve the same aim as tabs — expressing structure — but with fewer moving parts. After a few decades of working on large, shared codebases, I’ve come to value that reduction in ambiguity more than the flexibility tabs provide.

This is why I enable “insert spaces instead of tabs” in every editor I use. Not out of dogma, but because it removes an entire category of avoidable problems.

tabs vs spaces: The real problem isn’t tabs — it’s inconsistency

If there is a genuine villain in this debate, it’s inconsistency.

Mixing tabs and spaces without a clearly enforced standard is a reliable way to:

• Break visual structure
• Generate noisy diffs
• Turn code reviews into archaeology

Fortunately, this is much easier to manage today than it was when this debate first flared up.

tabs vs spaces in Code: A brief note on modern tooling

In 2026, this debate is far less painful thanks to tooling:

• EditorConfig allows projects to declare indentation rules once and have them respected across editors.
• Auto-formatters (Prettier, Black, gofmt, clang-format, rustfmt) remove human inconsistency entirely.
• Linters and CI checks can enforce formatting automatically and objectively.
• IDE defaults are far better than they used to be, and much easier to standardise.

With the right tools in place, teams can safely use tabs or spaces and still achieve clean, readable, consistent code.

Closing thoughts

Tabs vs spaces isn’t a moral issue, and it isn’t a measure of engineering quality. It’s a trade-off between flexibility and determinism.

I choose spaces because they give me the same outcome with fewer surprises. Others choose tabs for equally valid reasons. What matters far more than the choice itself is that teams agree, document it, and let tooling enforce it.

After fifty years on this planet — and many of them writing code — I’ve learned that consistency beats ideology every time.

Footnote:
This piece is a rewrite of a much more forcefully worded post I originally wrote in 2009. At the time, the tabs vs spaces debate felt like a hill worth dying on. With a few more decades of experience — and a lot more shared codebases behind me — I’ve come to value consistency, tooling, and pragmatism far more than winning arguments. I still prefer spaces, for the reasons outlined above, but I’m much happier these days letting formatters and standards do the heavy lifting.

Like any exam, it is important to understand the subject’s key concepts. These are:

• Cluster Architecture
• Cluster installation (non-managed service)
• Networking
• Scheduling
• Security
• Troubleshooting

The steps I took for revision included setting up a cluster from scratch using kubeadm, I also played with kops a little, but you should focus on kubeadm. When I did this, I also focused on installing networking plugins; at the time, I used flannel and weave, but there are others, like calico, flannel is easy to understand in the first instance.

Core concepts to understand are:

• Pods
• Deployments
• Services
• Namespaces
• Configmaps
• Secrets
• Persistent Volumes
• Persistent Volume Claims

Networking models to understand thoroughly would be

• Services:
  • ClusterIP
  • NodePort
  • Loadbalancer
• Ingress
  • Ingress itself
  • Ingress Controllers
• DNS

Troubleshooting, this is a little more complicated. You should know how the kubelet works, what it’s for, what common config files are used in a cluster, and where they sit on the Linux file system.

I cannot stress enough that you need to do be able to do this on the cli with no fancy guis. Also, the exam drops you in a shell with vi editor or nano, and that’s it, so you need to be comfortable in this environment; if you are not, you will not do well.

Pod scheduling and security concepts to understand would be

• Role-based Access control (RBAC)
• Service accounts
• Network policies
• Pod Security Admission
• Kubernetes audit and logging mechanisms

Cluster maintenance, you should practice

• adding and removing nodes from the cluster
• upgrading Kubernetes clusters
• upgrade a linux machine installed as a node
• replacing expired certificates
• backing up etcd
• assigning pods to nodes

So this is what to learn, but where can I learn this? The Kubernetes documentation is very, very good. To learn the kubectl tool, you can look at the cheat sheet. I spent a lot of time on this, and it was worth it as many of the questions I was asked had their answers rooted in these commands; I also found using kubectl explain useful for reminders.

Other learning resources

• Killercoda has some excellent environments, and I used these.
• KodeKloud Training has a great CKA course on Udemy.
• Killer Shell has a good run-through of their preview simulator available, which gives you a good idea of the depth you can expect to need to know, its harder than the exam and you get two instances of this when you sign up, do not make the mistake of not doing this, if you pass this well then its a good indication you are ready, if you score a low score, perhaps think twice about taking the exam soon.

In addition, I set up a home cluster using Raspberry Pi, but if you cannot stretch to that, you can use kops and virtual box to do so. The lowest entry barrier is installing Docker Desktop and enabling Kubernetes there, which will get you started with no fuss and the ability to learn kubectl commands. The docker desktop method, however, is not enough to learn how to set up a cluster from scratch.

If you give all this a good go you should be ready do some practice exams to be sure. One last thing which will be of interest but not strictly necessary for the exam, I always say after this read an article that was pointed out to me by a colleague some time ago and that is Ian lewis’s article The almighty pause container. Honestly I learned so much reading that. Ian also does an amazing job explaining Pods

Unable to connect to the server: x509: certificate has expired or is not yet valid: <timestamp here>

The next step is to renew these certificates to restore communication you can do this with kubeadm. So issue the following command:

sudo kubeadm alpha certs renew all

You will then get output which looks something like this as the certificates are renewed:

certificate embedded in the kubeconfig file for the admin to use and for kubeadm itself renewed
certificate for serving the Kubernetes API renewed
certificate the apiserver uses to access etcd renewed
certificate for the API server to connect to kubelet renewed
certificate embedded in the kubeconfig file for the controller manager to use renewed
certificate for liveness probes to healthcheck etcd renewed
certificate for etcd nodes to communicate with each other renewed
certificate for serving etcd renewed
certificate for the front proxy client renewed
certificate embedded in the kubeconfig file for the scheduler manager to use renewed

Kubernetes will then output that you need to restart api-server, controller-manager and kubelet so they can use the new certificates you have created, the quickest (and dirtiest) way in a simple home lab cluster to do this is to reboot the control plane. Before you restart you need to manage the configuration so backup the old one if you like then issue the following command.

sudo cp /etc/kubernetes/admin.conf ~/.kube/config

Now restart your control plane node(s). Upon reboot you should find that after the cluster settles you are able to check the current certificates with:

sudo kubeadm certs check-expiration

Which would yield output like this:

CERTIFICATE                EXPIRES                  RESIDUAL TIME   CERTIFICATE AUTHORITY   EXTERNALLY MANAGED
admin.conf                 Feb 16, 2024 12:16 UTC   364d                                    no
apiserver                  Feb 16, 2024 12:16 UTC   364d            ca                      no
apiserver-etcd-client      Feb 16, 2024 12:16 UTC   364d            etcd-ca                 no
apiserver-kubelet-client   Feb 16, 2024 12:17 UTC   364d            ca                      no
controller-manager.conf    Feb 16, 2024 12:17 UTC   364d                                    no
etcd-healthcheck-client    Feb 16, 2024 12:17 UTC   364d            etcd-ca                 no
etcd-peer                  Feb 16, 2024 12:17 UTC   364d            etcd-ca                 no
etcd-server                Feb 16, 2024 12:17 UTC   364d            etcd-ca                 no
front-proxy-client         Feb 16, 2024 12:17 UTC   364d            front-proxy-ca          no
scheduler.conf             Feb 16, 2024 12:17 UTC   364d                                    no

Arguably you should be doing this before your certs expire to not loose communication but the process is the same for renewal.

If you prefer not to reboot, which admittedly is the dirty way to do this, you can restart the kubelet on the master node, as a note the kube-apiserver runs as a static pod.

system restart kubelet

When you issue that command all of the kube-<name> services should restart.

Suppose you want to use an ACM certificate with an EC2 instance. You can associate the certificate with an Elastic Load Balancer (ELB) or CloudFront distribution in front of your EC2 instances. This allows you to secure traffic to your EC2 instances using SSL/TLS.

After understanding this, I was further confused by people saying that I could use the Private CA feature of ACM to provide certificates to EC2 instances; at this time, I had only ever used Private CAs to be associated with ACM, so I assumed we couldn’t use these CAs with EC2. That assumption was incorrect. The process to do this is as follows:

1. Create an AWS Private CA in the AWS Certificate Manager (ACM) Private CA section.
2. Create a certificate signing request (CSR) on the EC2 instance where the certificate will be used.
3. Use the CSR to request a certificate from the AWS Private CA in the ACM Private CA service.
4. Once the certificate is issued, download and install it on the EC2 instance where it will be used.
5. Configure your EC2 instance to use the newly-installed certificate.

Always remember that if you do this, you should ensure that your certificates are valid. Also, take care of rotation; they will not be automatically rotated with you configuring that yourself. A good way of achieving this using managed services would be, for example, by using AWS SSM to install these certificates.

Configuration of certificate deployment is dependent on the technology you use; for an apache web server on Amazon Linux for example, you would need to ensure mod_ssl is installed, and then the certificates and private key, and chain are deployed to the appropriate locations for that software. /etc/certs.

Today I took and passed my AWS Solutions Architect Professional exam. I’ve been working with AWS now for about 5 years. I Originally passed the Associate exam all the way back in December 2016. Back then I was as pleased as punch to have passed that exam and ever since then I’ve enjoyed working with Amazon’s cloud offering.

Just recently I’ve wanted to cement my learning and pass the professional exam. For me it was about proving to myself I could pass a top-flight cloud exam but also about the learning journey that came with being able to pass it.

To make sure I knew enough I started by brushing up on courses I had in A Cloud Guru and once that was done I purchased a course on Udemy by Stephane Maarek called “Ultimate AWS Certified Architect Professional 2021”. This course was really well-paced and covered a lot of ground, along with the hands-on experience I found this prepared me really well for the exam. After that I read a couple of whitepapers as well and Took a practice exam (which I passed). I am now the proud owner of the certification. I wonder what my next challenge will be.

You can view my badge here: https://www.credly.com/badges/0adf99df-c39f-4c66-96d6-ca67c5830d7c/public_url

After a while AWS Lambda functions became extremely popular, now we don’t even need containers, we can take little pieces of code have them exist in “lambda land” and not really worry about what it is that’s serving them because that’s all managed for us. To make matters better if you design correctly lambdas are extremely cheap and you only pay for the execution time. Meanwhile, of course, Amazon released Fargate over in ECS and you then didn’t need to worry about provisioning your ECS instances anymore. But which one is right for which.

Let’s take a look at Lambda first, we’ll be using the following:

• Serverless Framework
• NodeJs
• AWS Lambda
• AWS CloudFormation
• AWS API Gateway

If you haven’t used any of this before, don’t worry the cloudformation isn’t something we will be writing directly, the Serverless Framework will take care of that for us for now, it will create a “Stack” which will deploy our lambda functions and our API Gateway endpoints, the endpoints will front our lambda functions.

So first things first we need a serverless project, we are going to use the open-source version of the serverless framework, there is a commercial offering but you don’t need to worry about that to get started. The framework runs on NodeJs 6 or higher but we will be using version 10 of node js to remain current as of time of writing so after you have installed NodeJs for your platform you need to install serverless which you can do with the following line:

npm install -g serverless

You can find out what version you are running with

serverless --version

As we are going to deploy to Amazon Webservices we are going to need login credentials for the framework to use, this is a large topic so I am not going to detail that here, however, the guys over at serverless.com have written a fantastic set of instructions which you should follow and then come back.

Following in the tradition of all frameworks these days the serverless cli you installed above has a way of creating projects so you can get started quickly, here we create a service, which is like a project with the following command.

serverless create --template aws-nodejs --path myFirstService

You will get some output that looks like this

Serverless: Generating boilerplate in "/home/krystan/projects/serverless_article/myFirstService"
 _______                             __
|   _   .-----.----.--.--.-----.----|  .-----.-----.-----.
|   |___|  -__|   _|  |  |  -__|   _|  |  -__|__ --|__ --|
|____   |_____|__|  \___/|_____|__| |__|_____|_____|_____|
|   |   |             The Serverless Application Framework
|       |                           serverless.com, v1.52.0
 -------'

Serverless: Successfully generated boilerplate for template: "aws-nodejs"

In the directory “myFirstService” you will have two files, one called serverless.yml and one called handler.js. The most important file is the yml file, this is where you define the application and where you want it deployed. Each serverless service can be thought of as an application, it can have many lambda functions associated with it. Each application is housed in its own directory with its own distinct serverless.yml file. When you execute the deploy stage serverless framework reads the .yml file and take your code and deploys it for you, creating all the infrastructure you need in AWS. It does this by using Amazon Cloudformation under the covers, this is an infrastructure as code (IAC) tool written by Amazon.

At this point it’s worth pointing out that serverless platform can deploy to different clouds, it is not just AWS specific and it does so by making use of different providers, for this article we will stick to the AWS Provider as we are deploying to that cloud.

Let’s take a look at the yml file we shall be using, the one produced by the framework is quite verbose and has a lot of comments in, for this article, we shall use a paired down version that looks like this:

service: myfirstservice
frameworkVersion: "=1.52.0"

provider:
  name: aws
  runtime: nodejs10.x
  stage: dev
  region: eu-west-1
  apiName: ${self:provider.stage}-myfirstservice
  memorySize: 512

functions:
  hello:
    handler: handler.hello
    events:
      - http: GET hello
  tags:
      environment: ${self:provider.stage}
      serverless: true

There is a lot going on here but we have defined an AWS provider so we can deploy to AWS, told the framework we are using nodejs10.x (these types can be found in AWS documentation for languages supported, you don’t have to use NodeJs). The stage can be thought of your environment, so for example, you may have; dev, test, uat and then prod stages. We give the API Gateway deployment a name overriding the default, this is making use of variables, in this case, it refers to itself and the provider and accesses the stage name to produce:

dev-myfirstservice

We then give a starting memory size for the lambda function. We add some tags (because tagging things is good practice) and tell the framework where the code is to build the lambda function. We then associate an HTTP GET event with that handler. The handler code as generated by the serverless framework looks like this:

'use strict';

module.exports.hello = async event => {
  return {
    statusCode: 200,
    body: JSON.stringify(
      {
        message: 'Go Serverless v1.0! Your function executed successfully!',
        input: event,
      },
      null,
      2
    ),
  };
};

Its really just a hello world function but will do for now. Now lets deploy by typing:

serverless deploy

We will get some output which looks something like this

$ serverless deploy
Serverless: Packaging service...
Serverless: Excluding development dependencies...
Serverless: Creating Stack...
Serverless: Checking Stack create progress...
.....
Serverless: Stack create finished...
Serverless: Uploading CloudFormation file to S3...
Serverless: Uploading artifacts...
Serverless: Uploading service myfirstservice.zip file to S3 (319 B)...
Serverless: Validating template...
Serverless: Updating Stack...
Serverless: Checking Stack update progress...
...............................
Serverless: Stack update finished...
Service Information
service: myfirstservice
stage: dev
region: eu-west-1
stack: myfirstservice-dev
resources: 10
api keys:
  None
endpoints:
  GET - https://quqruaplt8.execute-api.eu-west-1.amazonaws.com/dev/hello
functions:
  hello: myfirstservice-dev-hello
layers:
  None
Serverless: Run the "serverless" command to setup monitoring, troubleshooting and testing.

This has done an awful lot for us, if we were to do this manually we would need to compile and package the lambda code, define the function and then upload the code to either a bucket or use the built-in bucket mechanism of lambda. If we wanted it repeatable we’d need to write a lot of Terraform or Cloudformation definitions to do that and then set up a mechanism to create that (probably scripts). This did all of that in one command. Lets have a look: We can list the lambda with the aws-cli like this:

aws lambda get-function --function-name myfirstservice-dev-hello --region=eu-west-1

You will get some output which looks a little like this:

{
    "Configuration": {
        "FunctionName": "myfirstservice-dev-hello",
        "FunctionArn": "arn:aws:lambda:eu-west-1:<redacted>:function:myfirstservice-dev-hello",
        "Runtime": "nodejs10.x",
        "Role": "arn:aws:iam::<redacted>:role/myfirstservice-dev-eu-west-1-lambdaRole",
        "Handler": "handler.hello",
        "CodeSize": 319,
        "Description": "",
        "Timeout": 6,
        "MemorySize": 512,
        "LastModified": "2019-09-15T22:22:31.822+0000",
        "CodeSha256": "nAMhMEam8QPdOjMJ9JdnIYAsIZc2JUnZWrXs5/+BwT0=",
        "Version": "$LATEST",
        "TracingConfig": {
            "Mode": "PassThrough"
        },
        "RevisionId": "255e1518-f325-4609-bc52-b731a18b8b57"
    },
    "Code": {
        "RepositoryType": "S3",
        "Location": "https://awslambda-eu-west-1-tasks.s3.eu-west-1.amazonaws.com/snapshots/<redacted>/myfirstservice-dev-hello-033b62e1-fafd-4b6f-b936-9fcf51c545fb?versionId=sNo8GB0HJVbnp.sLGHYFgq.jGl.33aXH&X-Amz-Security-Token=AgoJb3JpZ2luX2VjEIX%2F%2F%2F%2F%2F%2F%2F%2F%2F%2FwEaCWV1LXdlc3QtMSJGMEQCIH6x8MzeUx%2FjUvY90hihQOQPd4Jq1Kv0ikaUBXMZut2GAiAu%2BKf%2BSOrrqHEQwWJdL5zDJOqt5FjWcvobQttqO6e0%2FiraAwhOEAEaDDk1NDM2OTA4MjUxMSIMmXidpPgv4z%2FLvAM9KrcDwJ47KqHJ7obSPTLC2qY4VcHzIjfrXCYbt08Jp%2BPA9Vf01%2BbifjCM9SpAolq4wJmGZH5eri5g7rvcCkspuMjc%2FP%2BQSBjM5J59NZyGoHUG1uAR6E%2F2vt95RSPGmxXPNxah5CzYJ4kkVWP0nFErv0ZScJvhf1iYsfdcowW7%2F%2F6EgMfNwtvJ84hz9ie0EK%2FR4Tnnf%2BNJSsthK2n%2BP6s0%2BA8Y0et4k2ea7rsfYAheW9JkuPM6kwev%2B6sFvZuOyaH9XObSkqd12EzkBJI2fyLKzuBXrBrE%2FFWIXBMdcUt4G7F9Lin2a0Ak0r2joU4gCl7gYPpfBZhzii5MglNSpVx5x4JxZHu%2Brw7MRsbblIHA9bLCYLG9yIB1oAUJQ3wprVINqpyuSHVuEgJGCQR9L8E%2Fs0vq%2Btw6HeW5ztoIoysuHxoee9Iy%2F2R7oDNxeart9aF2sxUqrzwzfdmyX%2FpVALW7wB0w2sIQWCiARXzURybXRnfBVEP3q9XmXi0C2Wowf2rzpr33Wr%2FXCl%2FF03tVXrEjBVez%2FGWfGn%2B%2BEtagFCNpfErVK5%2B4BioLubU8VnPkoGk5pZyq94kDcBfBtTDfz%2FrrBTq1AdKN40bQ1SHXprJcF%2Bowapjm2LjslDgWs9UdmvAeAP9LEJjDHx8UN9Tyc1Mws3ePrHBd%2BuFOVXyZaFZej%2FHa8afSBTyGCxW9wUwnm6iT79vHHhMgaiXx0iYl69iMjRfsJ8Lc5c37mRddhzWUK3%2B2aheFy%2BaweV7xVqQ8ryrKZUaFUEU2uJ%2BcgcS36HCcETfHFuxTMe%2B6FGyZsm%2BGSNbC1%2B0Ncn6OTSVXKBTRz8S%2FujPzTpTNEWY%3D&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Date=20190915T222856Z&X-Amz-SignedHeaders=host&X-Amz-Expires=600&X-Amz-Credential=ASIA54NGUQSHV34AKUNC%2F20190915%2Feu-west-1%2Fs3%2Faws4_request&X-Amz-Signature=ee9260d791cbf1accbccc5fa7a684f10ff7f2846a164f843c7891426e9e6989c"
    },
    "Tags": {
        "STAGE": "dev",
        "aws:cloudformation:logical-id": "HelloLambdaFunction",
        "aws:cloudformation:stack-id": "arn:aws:cloudformation:eu-west-1:<redacted>:stack/myfirstservice-dev/32634cd0-d807-11e9-b10e-02abe6210ac8",
        "aws:cloudformation:stack-name": "myfirstservice-dev",
        "environment": "dev",
        "serverless": "true"
    }
}

You can see here the lambda is defined and referred to in a cloud formation stack, as you make more deploys these changes are managed and resources managed for you if you remove an endpoint definition for API Gateway, it will be deleted and so on.

So how do we know this all works, serverless has some tools for testing, we can invoke the function directly from the command line with the following command:

serverless invoke --function hello

This makes a call to the function in the cloud and we get a response, that is a json response as we setup the lambda to return JSON so the lambda proxy for API Gateway could make use of it.

{
“statusCode”: 200,
“body”: “{\n \”message\”: \”Go Serverless v1.0! Your function executed successfully!\”,\n \”input\”: {}\n}”
}

This is the response directly from the function, but what about the API Gateway, well the response from that is a little more verbose you can test with curl and this is what it looks like:

curl https://quqruaplt8.execute-api.eu-west-1.amazonaws.com/dev/hello
{
  "message": "Go Serverless v1.0! Your function executed successfully!",
  "input": {
    "resource": "/hello",
    "path": "/hello",
    "httpMethod": "GET",
    "headers": {
      "Accept": "*/*",
      "CloudFront-Forwarded-Proto": "https",
      "CloudFront-Is-Desktop-Viewer": "true",
      "CloudFront-Is-Mobile-Viewer": "false",
      "CloudFront-Is-SmartTV-Viewer": "false",
      "CloudFront-Is-Tablet-Viewer": "false",
      "CloudFront-Viewer-Country": "GB",
      "Host": "quqruaplt8.execute-api.eu-west-1.amazonaws.com",
      "User-Agent": "curl/7.58.0",
      "Via": "2.0 42322007e22ea6a235ae829b1f254f98.cloudfront.net (CloudFront)",
      "X-Amz-Cf-Id": "1a86mebsjxXKlRgtL1cgAQfEnzCR9jrjzjgWeT2kfIuGciUQZX0Cug==",
      "X-Amzn-Trace-Id": "Root=1-5d7ebeff-babadb407ddaa92c52a236a2",
      "X-Forwarded-For": "<redacted>, <redacted>",
      "X-Forwarded-Port": "443",
      "X-Forwarded-Proto": "https"
    },
    "multiValueHeaders": {
      "Accept": [
        "*/*"
      ],
      "CloudFront-Forwarded-Proto": [
        "https"
      ],
      "CloudFront-Is-Desktop-Viewer": [
        "true"
      ],
      "CloudFront-Is-Mobile-Viewer": [
        "false"
      ],
      "CloudFront-Is-SmartTV-Viewer": [
        "false"
      ],
      "CloudFront-Is-Tablet-Viewer": [
        "false"
      ],
      "CloudFront-Viewer-Country": [
        "GB"
      ],
      "Host": [
        "quqruaplt8.execute-api.eu-west-1.amazonaws.com"
      ],
      "User-Agent": [
        "curl/7.58.0"
      ],
      "Via": [
        "2.0 42322007e22ea6a235ae829b1f254f98.cloudfront.net (CloudFront)"
      ],
      "X-Amz-Cf-Id": [
        "1a86mebsjxXKlRgtL1cgAQfEnzCR9jrjzjgWeT2kfIuGciUQZX0Cug=="
      ],
      "X-Amzn-Trace-Id": [
        "Root=1-5d7ebeff-babadb407ddaa92c52a236a2"
      ],
      "X-Forwarded-For": [
        "<redacted>, <redacted>"
      ],
      "X-Forwarded-Port": [
        "443"
      ],
      "X-Forwarded-Proto": [
        "https"
      ]
    },
    "queryStringParameters": null,
    "multiValueQueryStringParameters": null,
    "pathParameters": null,
    "stageVariables": null,
    "requestContext": {
      "resourceId": "x9w0yw",
      "resourcePath": "/hello",
      "httpMethod": "GET",
      "extendedRequestId": "AFLH-F_mjoEFT8Q=",
      "requestTime": "15/Sep/2019:22:45:19 +0000",
      "path": "/dev/hello",
      "accountId": "142273029879",
      "protocol": "HTTP/1.1",
      "stage": "dev",
      "domainPrefix": "quqruaplt8",
      "requestTimeEpoch": 1568587519762,
      "requestId": "163fd6df-c4db-4898-8f9e-4ff6245bf78b",
      "identity": {
        "cognitoIdentityPoolId": null,
        "accountId": null,
        "cognitoIdentityId": null,
        "caller": null,
        "sourceIp": "86.28.138.172",
        "principalOrgId": null,
        "accessKey": null,
        "cognitoAuthenticationType": null,
        "cognitoAuthenticationProvider": null,
        "userArn": null,
        "userAgent": "curl/7.58.0",
        "user": null
      },
      "domainName": "quqruaplt8.execute-api.eu-west-1.amazonaws.com",
      "apiId": "quqruaplt8"
    },
    "body": null,
    "isBase64Encoded": false
  }
}

Obviously you will need to use the id which serverless told you when you deployed but the domain name will almost definitely be the same so it should take the form <id>.execute-api.<region>.amazonaws.com.

This has covered getting up and running with serverless framework in AWS, now we are finished we should tidy up, we can do so by removing the stack which will delete the resources provisioned, we can do so by typing this:

serverless remove --verbose

I used the verbose flag so we can get some output to see what happens when we do this, this was the output I got:

Serverless: Getting all objects in S3 bucket...
Serverless: Removing objects in S3 bucket...
Serverless: Removing Stack...
Serverless: Checking Stack removal progress...
CloudFormation - DELETE_IN_PROGRESS - AWS::CloudFormation::Stack - myfirstservice-dev
CloudFormation - DELETE_IN_PROGRESS - AWS::Lambda::Permission - HelloLambdaPermissionApiGateway
CloudFormation - DELETE_IN_PROGRESS - AWS::ApiGateway::Deployment - ApiGatewayDeployment1568586098127
CloudFormation - DELETE_SKIPPED - AWS::Lambda::Version - HelloLambdaVersionbsuDYFOakPR8fC7BZCJsELhtJfq62Usj2akOdNzcPM
CloudFormation - DELETE_COMPLETE - AWS::ApiGateway::Deployment - ApiGatewayDeployment1568586098127
CloudFormation - DELETE_IN_PROGRESS - AWS::ApiGateway::Method - ApiGatewayMethodHelloGet
CloudFormation - DELETE_COMPLETE - AWS::ApiGateway::Method - ApiGatewayMethodHelloGet
CloudFormation - DELETE_IN_PROGRESS - AWS::ApiGateway::Resource - ApiGatewayResourceHello
CloudFormation - DELETE_COMPLETE - AWS::ApiGateway::Resource - ApiGatewayResourceHello
CloudFormation - DELETE_COMPLETE - AWS::Lambda::Permission - HelloLambdaPermissionApiGateway
CloudFormation - DELETE_IN_PROGRESS - AWS::Lambda::Function - HelloLambdaFunction
CloudFormation - DELETE_IN_PROGRESS - AWS::ApiGateway::RestApi - ApiGatewayRestApi
CloudFormation - DELETE_COMPLETE - AWS::Lambda::Function - HelloLambdaFunction
CloudFormation - DELETE_COMPLETE - AWS::ApiGateway::RestApi - ApiGatewayRestApi
CloudFormation - DELETE_IN_PROGRESS - AWS::Logs::LogGroup - HelloLogGroup
CloudFormation - DELETE_IN_PROGRESS - AWS::IAM::Role - IamRoleLambdaExecution
CloudFormation - DELETE_IN_PROGRESS - AWS::S3::Bucket - ServerlessDeploymentBucket
CloudFormation - DELETE_COMPLETE - AWS::Logs::LogGroup - HelloLogGroup
CloudFormation - DELETE_COMPLETE - AWS::S3::Bucket - ServerlessDeploymentBucket
Serverless: Stack removal finished...

As you can see it first emptied the deployment bucket and then triggered the stack removal when this happened the resources were removed.

We have barely scratched the surface of what can be done with the serverless framework, the next steps are up to you

Installation

Packer is a available here for most popular architectures and is not a complex product to install, in this article as I use Linux most frequently we will show the installation of packer for Linux, but it is similar on almost every platform.

To download packer you simply need to download the zip file from the distribution site, I did that like this:

export VER="1.4.3"
wget https://releases.hashicorp.com/packer/${VER}/packer_${VER}_linux_amd64.zip
unzip packer_${VER}_linux_amd64.zip -d packer
sudo mv packer /usr/local/bin/

Once installed you can confirm it is there by calling packer and you should get output similar to the following:

$ packer
Usage: packer [--version] [--help] <command> [<args>]

Available commands are:
    build       build image(s) from template
    console     creates a console for testing variable interpolation
    fix         fixes templates from old versions of packer
    inspect     see components of a template
    validate    check that a template is valid
    version     Prints the Packer version

After this packer is ready to use. Packer using builders to generate images that you can deploy. There are a number of templates you can use and a list is provided on the packer site here. A common builder to us is the amazon-ebs builder which we will use for the purposes of this article, this will allow us to create Amazon Machine Images, it does this by launching an E2 instance and then creating a golden image from that instance from which other machines can be created. It then drops that in your account for you to manage. A first template configuration may look like this:

{
  "variables": {
    "aws_access_key": "{{env `AWS_ACCESS_KEY_ID`}}",
    "aws_secret_key": "{{env `AWS_SECRET_ACCESS_KEY`}}"
  },
  "builders": [
    {
      "type": "amazon-ebs",
      "access_key": "{{user `aws_access_key`}}",
      "secret_key": "{{user `aws_secret_key`}}",
      "region": "eu-west-1",
      "source_ami": "ami-06358f49b5839867c",
      "instance_type": "t2.micro",
      "ssh_username": "ubuntu",
      "ami_name": "packer_article {{timestamp}}"
    }
  ],
  "provisioners": [
    {
      "type": "shell",
      "script": "demo-script"
    }
  ]
}

This is perfectly valid but its not generally a good idea to pass in your access and secret keys in this way, this is merely an example to show how you can pass in variables to the builders, the credentials should simply be set in your aws config files as normal and this would leave us with a template which looks like this:

{
  "builders": [
    {
      "type": "amazon-ebs",
      "region": "eu-west-1",
      "source_ami": "ami-06358f49b5839867c",
      "instance_type": "t2.micro",
      "ssh_username": "ubuntu",
      "ami_name": "packer_article {{timestamp}}"
    }
  ],
  "provisioners": [
    {
      "type": "shell",
      "script": "configure-machine.sh"
    }
  ]
}

The basic parts of a template are:

• variables         – define any variables here.
• builders           – this is where the details for the AMI image go.  
• provisioners   – this are is where you can list various provisioners to configure the AMI.

Supported provisioners are:

• Ansible
• Chef
• Salt
• Shell
• Powershell
• Windows cmd
• File – this copies a local file to an VM image.

We are using a simple shell provisioner here which will launch a basic script to install nginx. This script looks like so:

#!/bin/bash
sudo yum -y update
sudo yum install -y nginx

Now you have your template defined the next step is to build the template.

packer validate
packer build -color=false build.json 2>&1 | tee output.txt

During this process you will get a bunch of output and above I have piped this to a file (which is why I used the color=false option or you will get a lot of ansi colour codes). The output should look something like this:

amazon-ebs: Prevalidating AMI Name: packer_article 1567873619
amazon-ebs: Found Image ID: ami-06358f49b5839867c
amazon-ebs: Creating temporary keypair: packer_5d73da53-1797-d184-50ef-190d3acf3f79
amazon-ebs: Creating temporary security group for this instance: packer_5d73da78-cc5c-3179-19bb-0164e574d474
amazon-ebs: Authorizing access to port 22 from [0.0.0.0/0] in the temporary security groups...
amazon-ebs: Launching a source AWS instance...
amazon-ebs: Adding tags to source instance
amazon-ebs: Adding tag: "Name": "Packer Builder"
amazon-ebs: Instance ID: i-09a8c7a2ac70cc31c
amazon-ebs: Waiting for instance (i-09a8c7a2ac70cc31c) to become ready...
amazon-ebs: Using ssh communicator to connect: 18.203.99.110
amazon-ebs: Waiting for SSH to become available...
amazon-ebs: Connected to SSH!
amazon-ebs: Provisioning with shell script: configure_machine.sh
amazon-ebs: Get:1 http://security.ubuntu.com/ubuntu bionic-security InRelease [88.7 kB]
amazon-ebs: Hit:2 http://archive.ubuntu.com/ubuntu bionic InRelease
amazon-ebs: Get:3 http://archive.ubuntu.com/ubuntu bionic-updates InRelease [88.7 kB]
amazon-ebs: Get:4 http://archive.ubuntu.com/ubuntu bionic-backports InRelease [74.6 kB]
amazon-ebs: Get:5 http://archive.ubuntu.com/ubuntu bionic/universe amd64 Packages [8570 kB]
amazon-ebs: Get:6 http://security.ubuntu.com/ubuntu bionic-security/main amd64 Packages [497 kB]
amazon-ebs: Get:7 http://archive.ubuntu.com/ubuntu bionic/universe Translation-en [4941 kB]
amazon-ebs: Get:8 http://security.ubuntu.com/ubuntu bionic-security/main Translation-en [169 kB]
amazon-ebs: Get:9 http://security.ubuntu.com/ubuntu bionic-security/restricted amd64 Packages [6296 B]
amazon-ebs: Get:10 http://security.ubuntu.com/ubuntu bionic-security/restricted Translation-en [2776 B]
amazon-ebs: Get:11 http://security.ubuntu.com/ubuntu bionic-security/universe amd64 Packages [604 kB]
amazon-ebs: Get:12 http://security.ubuntu.com/ubuntu bionic-security/universe Translation-en [201 kB]
amazon-ebs: Get:13 http://security.ubuntu.com/ubuntu bionic-security/multiverse amd64 Packages [4688 B]
amazon-ebs: Get:14 http://security.ubuntu.com/ubuntu bionic-security/multiverse Translation-en [2356 B]
amazon-ebs: Get:15 http://archive.ubuntu.com/ubuntu bionic/multiverse amd64 Packages [151 kB]
amazon-ebs: Get:16 http://archive.ubuntu.com/ubuntu bionic/multiverse Translation-en [108 kB]
amazon-ebs: Get:17 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages [722 kB]
amazon-ebs: Get:18 http://archive.ubuntu.com/ubuntu bionic-updates/main Translation-en [262 kB]
amazon-ebs: Get:19 http://archive.ubuntu.com/ubuntu bionic-updates/restricted amd64 Packages [13.1 kB]
amazon-ebs: Get:20 http://archive.ubuntu.com/ubuntu bionic-updates/restricted Translation-en [4448 B]
amazon-ebs: Get:21 http://archive.ubuntu.com/ubuntu bionic-updates/universe amd64 Packages [1003 kB]
amazon-ebs: Get:22 http://archive.ubuntu.com/ubuntu bionic-updates/universe Translation-en [308 kB]
amazon-ebs: Get:23 http://archive.ubuntu.com/ubuntu bionic-updates/multiverse amd64 Packages [7308 B]
amazon-ebs: Get:24 http://archive.ubuntu.com/ubuntu bionic-updates/multiverse Translation-en [3836 B]
amazon-ebs: Get:25 http://archive.ubuntu.com/ubuntu bionic-backports/main amd64 Packages [2512 B]
amazon-ebs: Get:26 http://archive.ubuntu.com/ubuntu bionic-backports/main Translation-en [1644 B]
amazon-ebs: Get:27 http://archive.ubuntu.com/ubuntu bionic-backports/universe amd64 Packages [4000 B]
amazon-ebs: Get:28 http://archive.ubuntu.com/ubuntu bionic-backports/universe Translation-en [1856 B]
amazon-ebs: Fetched 17.8 MB in 7s (2603 kB/s)
amazon-ebs: Reading package lists...
amazon-ebs: Reading package lists...
amazon-ebs: Building dependency tree...
amazon-ebs: Reading state information...
amazon-ebs: The following additional packages will be installed:
amazon-ebs:   libnginx-mod-http-echo nginx-common nginx-light
amazon-ebs: Suggested packages:
amazon-ebs:   fcgiwrap nginx-doc ssl-cert
amazon-ebs: The following NEW packages will be installed:
amazon-ebs:   libnginx-mod-http-echo nginx nginx-common nginx-light
amazon-ebs: 0 upgraded, 4 newly installed, 0 to remove and 14 not upgraded.
amazon-ebs: Need to get 452 kB of archives.
amazon-ebs: After this operation, 1554 kB of additional disk space will be used.
amazon-ebs: Get:1 http://security.ubuntu.com/ubuntu bionic-security/main amd64 nginx-common all 1.14.0-0ubuntu1.6 [37.3 kB]
amazon-ebs: Get:2 http://security.ubuntu.com/ubuntu bionic-security/universe amd64 libnginx-mod-http-echo amd64 1.14.0-0ubuntu1.6 [21.2 kB]
amazon-ebs: Get:3 http://security.ubuntu.com/ubuntu bionic-security/universe amd64 nginx-light amd64 1.14.0-0ubuntu1.6 [390 kB]
amazon-ebs: Get:4 http://security.ubuntu.com/ubuntu bionic-security/main amd64 nginx all 1.14.0-0ubuntu1.6 [3596 B]
amazon-ebs: debconf: unable to initialize frontend: Dialog
amazon-ebs: debconf: (Dialog frontend will not work on a dumb terminal, an emacs shell buffer, or without a controlling terminal.)
amazon-ebs: debconf: falling back to frontend: Readline
amazon-ebs: debconf: unable to initialize frontend: Readline
amazon-ebs: debconf: (This frontend requires a controlling tty.)
amazon-ebs: debconf: falling back to frontend: Teletype
amazon-ebs: dpkg-preconfigure: unable to re-open stdin:
amazon-ebs: Fetched 452 kB in 0s (2310 kB/s)
amazon-ebs: Selecting previously unselected package nginx-common.
amazon-ebs: (Reading database ... 56638 files and directories currently installed.)
amazon-ebs: Preparing to unpack .../nginx-common_1.14.0-0ubuntu1.6_all.deb ...
amazon-ebs: Unpacking nginx-common (1.14.0-0ubuntu1.6) ...
amazon-ebs: Selecting previously unselected package libnginx-mod-http-echo.
amazon-ebs: Preparing to unpack .../libnginx-mod-http-echo_1.14.0-0ubuntu1.6_amd64.deb ...
amazon-ebs: Unpacking libnginx-mod-http-echo (1.14.0-0ubuntu1.6) ...
amazon-ebs: Selecting previously unselected package nginx-light.
amazon-ebs: Preparing to unpack .../nginx-light_1.14.0-0ubuntu1.6_amd64.deb ...
amazon-ebs: Unpacking nginx-light (1.14.0-0ubuntu1.6) ...
amazon-ebs: Selecting previously unselected package nginx.
amazon-ebs: Preparing to unpack .../nginx_1.14.0-0ubuntu1.6_all.deb ...
amazon-ebs: Unpacking nginx (1.14.0-0ubuntu1.6) ...
amazon-ebs: Processing triggers for ufw (0.36-0ubuntu0.18.04.1) ...
amazon-ebs: Processing triggers for ureadahead (0.100.0-21) ...
amazon-ebs: Setting up nginx-common (1.14.0-0ubuntu1.6) ...
amazon-ebs: debconf: unable to initialize frontend: Dialog
amazon-ebs: debconf: (Dialog frontend will not work on a dumb terminal, an emacs shell buffer, or without a controlling terminal.)
amazon-ebs: debconf: falling back to frontend: Readline
amazon-ebs: Created symlink /etc/systemd/system/multi-user.target.wants/nginx.service → /lib/systemd/system/nginx.service.
amazon-ebs: Processing triggers for systemd (237-3ubuntu10.24) ...
amazon-ebs: Processing triggers for man-db (2.8.3-2ubuntu0.1) ...
amazon-ebs: Setting up libnginx-mod-http-echo (1.14.0-0ubuntu1.6) ...
amazon-ebs: Setting up nginx-light (1.14.0-0ubuntu1.6) ...
amazon-ebs: Setting up nginx (1.14.0-0ubuntu1.6) ...
amazon-ebs: Processing triggers for ureadahead (0.100.0-21) ...
amazon-ebs: Processing triggers for ufw (0.36-0ubuntu0.18.04.1) ...
amazon-ebs: Stopping the source instance...
amazon-ebs: Stopping instance
amazon-ebs: Waiting for the instance to stop...
amazon-ebs: Creating AMI packer_article 1567873619 from instance i-09a8c7a2ac70cc31c
amazon-ebs: AMI: ami-09511096fd8530040
amazon-ebs: Waiting for AMI to become ready...
amazon-ebs: Terminating the source AWS instance...
amazon-ebs: Cleaning up any extra volumes...
amazon-ebs: No volumes to clean up, skipping
amazon-ebs: Deleting temporary security group...
amazon-ebs: Deleting temporary keypair...
Build 'amazon-ebs' finished.

==> Builds finished. The artifacts of successful builds are:
--> amazon-ebs: AMIs were created:
eu-west-1: ami-09511096fd8530040

You can see that packer has now created a standard AMI and place it in our account, this is where packers management ends of our AMIS, it is up to us to manage them once built.

You can check out your image with the AWS console to make sure its there and get more information:

aws ec2 describe-images --image-ids ami-09511096fd8530040 --output=json

And you will get a fair amount of information back

{
    "Images": [
        {
            "Architecture": "x86_64",
            "CreationDate": "2019-09-07T16:29:32.000Z",
            "ImageId": "ami-09511096fd8530040",
            "ImageLocation": "<myaccountId>/packer_article 1567873619",
            "ImageType": "machine",
            "Public": false,
            "OwnerId": "<myaccountId>",
            "State": "available",
            "BlockDeviceMappings": [
                {
                    "DeviceName": "/dev/sda1",
                    "Ebs": {
                        "DeleteOnTermination": true,
                        "SnapshotId": "snap-000b743eca850ac19",
                        "VolumeSize": 8,
                        "VolumeType": "gp2",
                        "Encrypted": false
                    }
                },
                {
                    "DeviceName": "/dev/sdb",
                    "VirtualName": "ephemeral0"
                },
                {
                    "DeviceName": "/dev/sdc",
                    "VirtualName": "ephemeral1"
                }
            ],
            "EnaSupport": true,
            "Hypervisor": "xen",
            "Name": "packer_article 1567873619",
            "RootDeviceName": "/dev/sda1",
            "RootDeviceType": "ebs",
            "SriovNetSupport": "simple",
            "VirtualizationType": "hvm"
        }
    ]
}

There are a lot of configuration options with packer, far too many to go into in this short article but this should get most started. For those not wanting to type all this out you can find the code here

You need to pop over to Google Domains and click the “Manage My Domains” button and then choose the relevant domain and click click on the DNS menu button to the right you need to scroll down to the Custom resource records.

Now what you need to do is to add the records required by Mailgun to verify and authorise your domain, these are:

• TXT
• TXT (another one)
• MX
• MX (another one)
• CNAME (for message tracking)

TXT records (known as SPF and DKIM) are required to send and receive mail with Mailgun, they are detailed in the Domain Verifications & DNS sections of Mailgun. You add in values by using the simple GUI at the top the columns are Name, Type, TTL (Time to live) and Data. So an example set of information looks like this:

Obviously, the data here is not real. Pay attention to the MX record, there is a little black + next to the record after entering the first one to allow multiple records under the same key. Just click that to add the second record. In each case after filling out the information click the Add button and you should end up with a similar screen as above.

After this is complete just wait for your domain to verify, this doesn’t take very long.

That is until I realised I was going to need to sort out the SSL certificate that is installed by default. The image created by Bitnami comes with a dummy certificate which, to be honest, isn’t useful to us on our nice new shiny domain. So how to solve this, luckily there is a way that is free of charge for things like blogs and that is located over at Lets Encrypts website, anyone thinking SSL certificates still cost a small fortune for things like a small blog should read on.

So now you know about Lets Encrypt how do you go about using one of their certificates. Luckily that has been made pretty painless by the Lets Encrypt team and you can install and enable a certificate with the minimum of fuss. And you can do that like so:

Install and run the Lets Encrypt certbot program.

You could do this with a package manager but I went with the following:

After accessing your Lightsail instance via ssh create a directory

mkdir certbot
cd certbot

Download the certbot

wget https://dl.eff.org/certbot-auto
chmod a+x certbot-auto

Run the certbot for your domain (don’t forget all domain names in this case I have two)

./certbot-auto certonly --webroot -w /home/bitnami/apps/wordpress/htdocs/ \
-d yourdomainhere.com \
-d www.yourdomainhere.com

You now need to edit /home/bitnami/stack/apache2/conf/bitnami/bitnami.conf and make it look like the below picture, this means commenting out the default certificates and adding the new ones in.

Now you need to restart the WordPress stack, Bitnami have a script for doing this and you can do so by typing the following:

sudo /opt/bitnami/ctlscript.sh restart

Now when you refresh your browser (and use the HTTPS protocol and not the HTTP one) you should get that padlock you’d been wanting.

One quick reminder is that these certificates are only valid for 90 days you can run the tool again or you can set up a cron job to update this. In order to add a cron job to update this certificate do the following.

Open up the crontab (as root) with

crontab -e

Now add the following in the file that opened:

0 0,12 * * * python -c 'import random; import time; time.sleep(random.random() * 3600)' && /home/bitnami/certbot/certbot-auto renew && /opt/bitnami/ctlscript.sh restart

This code adds a random time factor so not everyone in the world hits the certbot servers at the same time, and restarts the server so the new certificate is used.

Hope this helps.

I started using AWS 2 years ago and I really liked the interface on offer and the number of services which seem to grow at an exponential rate. I became an AWS certified architect over a year ago and always meant to move my blog but never really got around to it. All of this stopped after Amazon launched Lightsail.

So what’s the big deal? In Lightsail Amazon has created a way to create a number of well used and popular pre-packaged server configurations, there are entire stacks or OS only configurations here is a screen shot to give you an idea of what is available at the current time.

You simply choose your region and your instance plan, which start at $5 a month and go to $80, give it a unique name and tell the interface how many of these instances you wish to launch, your first month is free!

You can launch these instances in a number of regions and availability zones:

You can add a launch script that will execute on first launch at the click of a button this can be shell script for Linux based instances or Powershell for the windows based instances. Once you have created your instance you are presented with a small panel with the name of the instance with all its information my blog one looks like this:

You will notice from the above picture that in the tile there are a number of things shown, there is a CLI icon (more about this in a moment), a standard menu icon where various simple commands can be launched from and its IP address along with Region and A-Z. Also you will notice across the top there are simplified menu items for other services, like networking (A very simple Route53 interface) and also the ability to give your instance a static IP address. Normally Route53 although a great service can be a bit overwhelming if you are not used to that sort of service, the simplified interface on offer allows you to create a DNS Zone and to create A-Records very easily without really needing to know what all that stuff really means (you really should know if you are hosting your own stuff). Its all wizard-driven and DNS zones are a free service, you just enter your domain name in the friendly dialog and click create. After you create your records in your zone you are presented with the nameservers being used, which you can feed to your domain registrar if you are using a third party the gui is beginner friendly and looks like this:

Notice you are not restricted to A records you can add CNAMES, MX and TXT records, whilst this is not as fully featured as Route53 we are in a limited service so I think what’s available is really great. In keeping with the making things very clear if you click that delete link the entire form is replaced with a huge big red button, it is made very clear that clicking that button will destroy all subdomains and traffic will no longer be routed to your instances.

So then how do you get into these instances? Well these are still EC2 instance configurations under the covers they don’t appear on the EC2 panel though, same as your hosted zone is nowhere to be found in the route53, don’t panic, you can assign keys to your instances, you can either generate your own keypair or use the default Lightsail ones. You could use ssh from a Linux command line or putty to connect to your instance but why when Lightsail gives you a client to do this with (remember that CLI icon I mentioned). Just click that icon and this appears:

You don’t even need a client or to memorise the ssh command (its not that hard) because you can click in and get a fully functional terminal right there in your browser. Its pretty impressive stuff and really does make it very easy to manage straight away without ever leaving the browser where you created the instance.

Other important features include being able to create disks, snapshots of the vm and create load balancers if you have created multiple instances. This is the sort of joined up thinking that makes Lightsail such a no brainer if all you want is a basic service configured quickly and launched into the cloud with minimum fuss. Which is really what the service is all about.

So once I had my server up and running and my domain functioning I simply used Vaultpress to migrate my content. There were a few issues with this, mainly to do with permissions on the Bitnami image but these were easily solved after a bit of research and once the Vaultpress user could write to the correct location it uploaded its helper script and my entire domain migrated in a few minutes. (All one post of it). Also my WordPress configuration came across.

One of the more annoying things that comes with this image is a little banner to bitnami in the bottom of your screen you can disable this it turns out with the following command:

sudo /opt/bitnami/apps/wordpress/bnconfig --disable_banner 1

and you can then use the following command to restart apache:

sudo /opt/bitnami/ctlscript.sh restart apache

This service has been about for a while now (November 2016) but I’ve really only just got around to looking at it. Its not meant to be an enterprise solution, its meant to be fast and easy and have a predictable price. Its really easy to use and it took me less than 15 minutes to get my instance up, routed, configured and restored (bar permissions issues), I hadn’t read the instructions but did know how dns worked. Its a great service.

Oh and if using guis upsets you there is a public API for doing all this here. And the lightsail docs I didn’t read are here.