Last week was Kubecon Europe, and that means a lot of announcements. Most of which I’ll ignore in this note, but I’ll mention the Operator Framework and gVisor. In addition, Stack Overflow released a Teams version and AWS CodeBuild supports local builds.
CoreOS initially introduced the concept of Operators into Kubernetes, applications that you can deploy and manage with the standard Kubernetes tools. Now they extended this with a framework for building Operators.
The framework consists of three tools; an SDK to quickly build, test, and package your Operator; a Lifecycle Manager to deal with deployments; and Operator Metering which allows you to limit usage. The combined goal of these tools is to make it easier to create and operate your Operators. If you have built, or are thinking of building, Operators you should check this out to see if it suits your needs. The project is open source with the code on GitHub.
gVisor is a new container runtime from Google. Its particular characteristic is that it offers more separation from the host than the regular runc container runtime, but is still lighter than a virtual machine. In effect, it trades performance and compatibility in favour of more security. As gVisor is OCI compatible it can easily replace the standard runtimes in both Docker and Kubernetes.
These downsides might not be worth it for every application, but if you want additional security, it could be worth looking into this.
Stack Overflow for Teams
Most of us will know and love Stack Overflow, that seeming repository of all programming knowledge, but what if there was a way to use that for your internal software and processes? That’s the use case for Stack Overflow for Teams, a method of extending Stack Overflow to create questions and answers for your internal teams.
It’s a different way of sharing knowledge than the usual wiki or intranet, and I can certainly see the attraction of it. Especially as it seamlessly integrates with Stack Overflow, meaning that you can search for the answers in the same place you always do. And specifically, it offers you a way to get an answer to your specific question in a way that is useful to others.
AWS CodeBuild Local Build
One downside for AWS CodeBuild, and most CI tools really, is that you often end up debugging your CI configuration. Or you have different ways of running the same commands locally and remotely. AWS CodeBuild now allows you to do so with its new local build ability.
Well, ability might be a bit of a big word. What it is is an agent, running in a Docker container. It works by getting a local copy of the CodeBuild build containers1 and passing that as an environment variable, along with other requirements, to the build agent container. The build agent will then spin up this container, execute your buildspec.yml file on it and give you your artefacts.
You’ll likely see the advantages of this, as it gives you a consistent way of running your build and debugging anything that might be wrong in the build process.
Or presumably any container you can use with CodeBuild. ↩︎
Read more like this:
- Week 23, 2018 - Amazon Neptune; ALB Built-in Authentication; Helm in CNCF
- Space Containers
- Week 43, 2019 - CloudWatch Anomaly Detection; Some AWS Container Updates
- Week 37, 2019 - Lambda Shared ENIs; EKS IAM Roles
- Week 34, 2019 - App Mesh Routing; Nested Step Functions; CodeBuild Runtimes
Or always get the latest by subscribing through RSS, Twitter, or email!