The first week of the year isn’t exactly exciting when it comes to news, so I’ll discuss some things from last year. As is so often the case when I’m looking back at a longer period, that means containers and serverless.
Secrets in ECS
I never got around to talking about it, but in November AWS released support for secrets in ECS. What this means is that you can define secrets from the Parameter Store in your task definitions and these then become available as environment variables. This means that you now have an easy way to securely make these secrets available to your Docker applications.
When this was released, there was a major shortcoming however. Secrets only worked in ECS on EC2, but not on the superior Fargate1. In good news however, this was rectified in December with platform version 1.32.
EKS Updates
While EKS didn’t get a lot of love during re:Invent, it did get some important updates after. First, a solution for upgrading your cluster is finally available. You can now update both Kubernetes and EKS platform versions on running clusters. EKS Platform versions are basically the extra glue that AWS puts on top of Kubernetes to make it work in EKS. That mostly means some patches and things like the API interface.
Obviously this is an important step in making EKS usable, but personally I liked the availability of EKS in new regions more. After all, one of those regions is Sydney and it was something I’d been waiting for. It happened just before Christmas though, so I haven’t actually gotten around to spinning a cluster up in Sydney3.
Serverless Updates
Today, I’m not going into the wonderful toys we got at re:Invent. I’ve got a dedicated post for that coming soon4.
When I wrote my review of the Serverless Application Repository you could only release applications and updates to them by going through the Console. This wasn’t a great process and obviously it also means that releasing those updates couldn’t be an automated process. With the new publish command from the SAM CLI this has now changed and you can finally do this from the command line and automate the process.
The last thing I should mention is WebSocket support in API Gateway. In case you’re not familiar with WebSockets, in short WebSockets API are a standardised way to enable two-way communication between the server5 and client. This means that the API Gateway will keep a connection in place, which in turn allows for more responsive applications as well as actions initiated by the application.
-
Well, superior in my opinion at least which should be obvious after all my talks. ↩︎
-
Although the rollout of that sounded a bit messy according to the note at the end, it all worked fine. ↩︎
-
I know, seems a bit unappreciative after asking for it so long. ↩︎
-
I’ve got a whole bunch of articles in various stages of completion, but I need to actually finish them so you can read them as well. I’ve heard that is more useful. ↩︎
-
Not exactly the right term when used with a serverless solution, but hopefully you understand what I mean. ↩︎
Read more like this:
- Using a Fargate Bastion for EKS Access
- Serverless Bastions on Demand
- ig.nore.me For 5 Minutes: AWS Fargate
- Week 37, 2019 - Lambda Shared ENIs; EKS IAM Roles
- Week 15, 2019 - Fargate and EKS Improvements; Shared Storage in Sydney; Australia's New Stupid Law
Or always get the latest by subscribing through RSS, Twitter, or email!