Another global Microsoft Azure outage today: how many outages have there been over the past few months?

Microsoft’s Azure cloud service had another major global outage today as a result of DNS issues, that impacted access to Office 365 (maybe it should be more realistically called Office 360-ish, give or take a few days of unexpected outages each year) and other services like Teams and Sharepoint.

There’s been a number of other significant outages over the past few months, which doesn’t give a good impression of Microsoft’s cloud reliability.

There was the multifactor access issue in November 2018 that again left users unable to logon for several hours.

In September 2018 there was the ‘weather related incident‘ related to a lightning strike near one of their datacenters in Texas. Although it only impacted Azure data centers in Texas, for some reason this outage had a cascading impact impacting access to Office 365 and related services across the US, with some users unable to access services for at least a day.

In June 2018 there was the datacenter cooling issue that took down access for most of Europe, another outage that lasted several hours.

What’s interesting in all these cases is that an issue impacting an Azure datacenter in a specific regional area impacted access to service across a much wider geographic area. You would think (or hope) there’s some planned level of cross region failover support for Azure services, but maybe there’s not?

AWS S3 error: “The bucket you are attempting to access must be addressed using the specified endpoint”

Most errors on AWS are explicit and self explanatory, but once in a while you run into something that tells you something went wrong, but not how to fix it.

When setting up an S3 bucket to serve a static website, I got this error being returned as 301s for referenced files:

<Error>
<Code>PermanentRedirect</Code>
<Message>The bucket you are attempting to access must be addressed using the specified endpoint. Please send all future requests to this endpoint.</Message>
<Endpoint>s3.amazonaws.com</Endpoint>
<Bucket>static</Bucket>
...
</Error>

If you click an object in a bucket and click the overview tab, you can get a URL direct to the object, for example:

To load a static site from S3 though, you need to use a URL referencing the bucket in the server name, so instead of this:

https://s3-us-west-1.amazonaws.com/react-sudoku-solver/index.html

You should use this:

http://react-sudoku-solver.s3-us-west-1.amazonaws.com/index.html

(I’m currently working on a React app as a Sudoku Solver – more on this later)

Kubernetes: creating a hostPath PersistentVolume in a single node cluster

To create a ‘hostPath’ PersistentVolume in a single node cluster (do not use in a cluster with more than 1 node):

kind: PersistentVolume
apiVersion: v1
metadata:
name: pv1
labels:
type: local
spec:
storageClassName: manual
capacity:
storage: 1Gi
accessModes:
- ReadWriteOnce
hostPath:
path: "/your-path-for-vol1"

If the above is pv1.yaml, apply with:

kubectl apply -f pv1.yaml

For more info, see the docs here.

Next steps: From NGINX WordPress and MySQL running on Docker, to Kubernetes

This website running this blog has been running in Docker containers on a small-ish 4GB VPS for the past 9 months pretty much issue free. You can follow by journey to migrate this site to Docker in posts here and here.

Since I’ve been spending time recently getting up to speed with Kubernetes, the next logic step would be to deploy to a Kubernetes cluster, which would give me an opportunity to find out what it takes to run Kubernetes. I’ve looked at managed offerings on Google and AWS, but the cost for a few small personal projects is a little more than I want to spend.

I have a 8GB VPS ready to go, so far installed with Docker and Kubernetes running as a single node cluster, and I’m starting to plan my strategy for migrating to this new server. The first thing I’ve been thinking about is whether I should take my existing Docker images and just deploy to Kubernetes as is. Where I’ve got stuck so far is I don’t know enough about how to run NGINX with WordPress and MySQL in multiple pods, so I think I might install the WordPress Chart using Helm and for the time being not worry about how to do this myself.

The next thing I’ve been looking at is how to configure an Ingress to access different deployed services via different urls. I’ve been looking at setting up Traefik as the Ingress Controller to do this, and will be sharing a post about that config shortly. What I’m interested in is being able to deploy a number of different projects, including my WordPress site, and have them accessed via different urls, and it looks like Traefik will handle this fine.

I plan on writing some further posts as I make this transition over the next couple of weeks.