Voice of the DBA

Tag: goals

  • Reviewing Your Past Efforts

    It’s about the start of a new year for me now. I know, it’s late February, and we’re almost a sixth of the way through the year, but I’ve been on sabbatical. In fact, with planning for the break, I’ve really missed almost two months of work at this point. I deliberately did not make any resolutions or planning at the end of 2019, since 2020 wouldn’t really start for my career until about now.

    Now is the time to plan, and I will do some writing on my blog for the things I want to tackle, but I also want to think about my plan. The main reason for this is the SQLskills newsletter from Jan 7 (#214), in which Paul Randal wrote an interesting editorial on the start of the New Year. There are a few things in the newsletter, but one of the items was about resolutions and planning for the new year, but by starting the process while looking at the previous year.

    I wrote about learning goals last year, and then blogged a bit about them throughout the first third of the year. I then pivoted a bit, with an outside commitment that ate up a bunch of my personal time. Despite having a reminder in my calendar, I never got back to the books I’d planned on reading.

    2019 Rating : Failure

    I’ll do more of a review on my blog, and then planning, but the important things I got from Paul’s note is that I didn’t go a good job of not only reviewing last year, but also I didn’t end up reviewing it periodically after a few months. Not only did my goal fail, but my review of my goal failed.

    There’s a lot to be gained from some self-analysis, and maybe even a review of your analysis by a spouse, partner, mentor, or close friend. In my case, I ended up doing more speaking and traveling than I’d expected, didn’t even complete my commitment, focused my reading time on fiction and escaping from life, and really ignored a bit of my career goals.

    I don’t know if I’ll do better this year, but just writing this and thinking about the process will help me do something different. Hopefully you are keeping up with your goals, but if not, maybe you need a mid year review, as I’m doing now.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Learning Kubernetes Security Concepts

    This post continues looking at my process of learning more about Kubernetes. I’ve been working through the 50 days of Kubernetes (K8s). Here I continue on with a few videos on secrets, configuration management and RBAC.

    Secrets

    I am glad that the idea of storing data securely has come to so many applications. Authentication, authorization, privileges, and more are complex and hard to get right. We continually see problems with passwords, certificates, and the link not being managed well.

    Kubernetes has the concept of secrets, which can be values or file contents (like a certificates). These can then be sent or mounted to containers for use.

    One problem, these are stored in the Kubernetes etcd (keyvalue store) in an unencrypted format. Kubernetes has new concepts to integrate into key management areas, like Azure Key Vault, to protect secrets, though Kubernetes privilege controls are still needed.

    A gross simplification, but I learned a little more about what secrets are.

    Configuration Management

    This is interesting to me, because I like abstracting things away. In Kubernetes, we abstract a configuration object as a separate entity, which can then be applied to a container/pod later. This also works through deployments, allowing configurations to be part of the rolling deployment, which can prevent issues.

    If you have good testing/evaluation of what is healthy. This is likely easier than comprehensive unit testing, but still.

    A good idea, just not sure if this is too much.

    RBAC

    I always think of this as row-based, but it’s really role-based, so maybe that should be the way I translate RBAC in my head.

    Like most systems that use RBAC, there is, of course, a role. The video wanders a bit in the explanation, but I’ll try to summarize what I learned. There are two facets to roles. First, these are verb/noun pairs that determine what permission is available for what resource. Like get/list for the verb, and pod, volume, service, etc. for the noun. These are setting up the permission side.

    However, there is another facet. These roles can be set as cluster roles, similar to server roles for SQL Server, or at the namespace level, more like a database role. In either case, you are scoping permissions. Obviously, be careful with cluster roles.

    The other side of this is the user. We can have users or groups used for these roles, similar to what is in SQL Server.

    A simple explanation, but at least I have some idea of the concept.

  • More Kubernetes Concepts

    This post continues looking at my process of learning more about Kubernetes. I’ve been working through the 50 days of Kubernetes (K8s). Now that I had a break from some travel, I went through a few videos in a short period of days. This post combines a few looks at Scenarios, storage, and stateful sets

    Scenarios

    This was a good look at how one of the founders see the Kubernetes being used. The initial idea was microservices, where many services each live in a container and communicate. Managing lots of containers, and lots of instances of each, is where Kubernetes excels.

    The second scenario is the diurnal or cyclical scenario where a load goes up and down each day/night, week/weekend, etc. Having Kubernetes manage the increase and decrease of workload is valuable, and if you’re in the cloud, then you’re not investing heavily in hardware that is unused.

    The third is with complex workflows, where one thing, then another, then another happens. I’m less sold here, but I do see that spin up/spin down, and having these workloads/processes in containers rather than on certain machines makes sense.

    Lastly, AI/ML places where all parts of your flow can access the Kubernetes API and spin things up and down or move workloads to better hardware, like GPU/FPU concentrated systems, that can help keep things moving.

    Good to see the different ways that this might be useful, though I was wondering if I’d see anything database related. I didn’t.

    Volumes and Storage

    The important thing for database workloads is storage. This is a constant question when I talk containers. What about the disks and storage and how does this work.

    This is a basic video, just noting that volumes are objects in K8s. They are attached to pods, but can be mounted (or not) inside containers in the pod. There is temp storage (/emptydir, need to look this one up), but we can also abstract away other storage with Persistent Volume Claims. These are the aspirational storage requirements that the container/pod needs.

    I’m not completely clear on these, and the explanation is a little light, so I’ll have to learn more later.

    Stateful Applications

    The last set of learning for this post. More relevant because SQL is a stateful application. Or so I thought.

    This really looks at stateful sets in Kubernetes, which are the ways in which we want orderly copies in a replica set. This means hostnames and DNS entries in stateful sets are ordered, and 0 based indexed. If I have a host of SalesSQL with 3 sets, I’ll get

    • SalesSQL-0
    • SalesSQL-1
    • SalesSQL-2

    Likewise, I may have salessql.mydomain.com, but I’ll also have the –0, –1, –2 DNS entries as well. The Kubernetes platform also will scale up and down from the end, adding or removing the next ordered element container.

    There can also be volumes associated here, or not, as your stateful application may have the need to use the same volume (like a clustered SQL Server) or separate volumes, like AGs. In any case, it’s a light explanation that I need to know more of.

    One thing I didn’t really like is that the data stores were associated as “cloud native storage applications”, not data stored or data platforms. Application developers I think sometimes forget there’s more to data than storage.

  • Kubernetes Pipelines

    This post continues looking at some of the Kubernetes concepts I’ve been learning with the 50 days of Kubernetes (K8s). Specifically in this post, I’m writing and thinking about the flow of containers from code to a Kubernetes cluster.

    The video talks about pipelines, which is the way in which you get code running in a Kubernetes cluster. The start looks at the idea that we don’t want arbitrary containers running in the cluster, so we limit access to the cluster to somewhere like a container registry, like Azure Container Registry. This ensures that only those containers loaded into your space get onto the cluster. No pulling from Docker Hub or some arbitrary location.

    However, then we worry about developers loading containers into the registry that haven’t been checked. So, we don’t give them permission, we give it to some CI/CD pipeline, which means any code written by a developer that builds a container has to be checked in.

    Now, we have a pipeline flow that we can control. As Brendon mentioned, this isn’t simple, and really, I think you have a lot of work here before you want to trust things running on a production Kubernetes cluster. Really now you need these in your CI pipeline:

    • Unit tests
    • Vulnerability scanning
    • credential scanning ( I see this from MS for Github repos)
    • every other type of scanning you can do

    In this way, you ensure some quality level in your containers as far as security goes and code working. The big win here, at least for me, is that you can continue to raise the bar by adding more tests and scans, something that’s hard to do for developers without automation.

    Not a lot new here, but certainly the idea of putting access and control into the CI/CD flow makes sense.