Articles, notes and random thoughts on Software Development and Technology
It’s pretty easy to set up and configure a new AWS Lambda with the AWS Console, but if you’re iterating on some changes and need to redeploy a few times, the AWS CLI makes it pretty easy.
To create a new Lambda, assuming you have a .zip packaged up and ready to go:
aws lambda create-function --function-name example-lambda --zip-file fileb://example-lambda.zip --handler index.handler --runtime nodejs8.10 --role arn:aws:iam::role-id-here:role/lambda-role
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?
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)
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.