Press "Enter" to skip to content

Category: Containers

Running SQL Server in a Local Container via VSCode

Published 2025-11-12 by Kevin Feasel

Eduardo Pivaral uses the MSSQL extension in Visual Studio Code:

You are a developer using SQL Server for your applications, and you need to quickly setup a local development environment. How can you make sure the environment is OS agnostic, so it can run on any operating system? Let’s see how we can quickly create a local container to run SQL Server using the VSCode MSSQL Extension.

Read on for the instructions. I still do the old-fashioned thing of opening up a terminal window and running docker commands, but this is pretty convenient.

Leave a Comment

Running Data API Builder in an Azure Container Instance

Published 2025-11-07 by Kevin Feasel

Jess Pomfret deploys an API:

This is post two in my series about the Data API Builder (dab), the first post, Data API Builder, covers what dab is and how to test it locally against SQL Server in running in a container. This was great for testing, but now we want to start to productionise this, and the first step is to get it running somewhere other than my laptop.

There are several deployment options available, I recommend you review the Microsoft docs here: Deployment guidance for Data API builder.

ACI wouldn’t necessarily be my first choice for, well, much of anything. However, it is cheap and easy, so it has that going for it.

Leave a Comment

Load Testing SQL Server with HammerDB and Docker

Published 2025-09-08 by Kevin Feasel

Anthony Nocentino announces a new tool:

I’m excited to announce the release of a new open-source project that fully automates HammerDB benchmarking for SQL Server using Docker. If you’ve ever needed to run TPC-C or TPC-H benchmarks multiple times, you know how time-consuming the manual setup can be. This project removes the hassle and gets you up and running a single command: ./loadtest.sh.

Click through to learn more about the project and how you can grab the code.

Comments closed

Defending Kubernetes

Published 2025-09-05 by Kevin Feasel

Joey D’Antoni defends the defensible:

I’ve seen a couple of posts (of course they were chock full of AI slop images) on LinkedIn in the last couple of weeks, talking about how challenging it is to implement Kubernetes. In the most recent post I saw, it stated that “it took 5 months for our CEO to implement Kubernetes for our app”, to which I would ask, why the hell is your CEO configuring your clusters. I designed, and implemented the Kubernetes infrastructure on my current project, and I’ve worked on for a while, so of course, I felt the need to share my opinions on the matter.

As far as Kubernetes on-premises goes, there are quite valid reasons to run it on-prem. Yeah, it’s easier to host in AKS or EKS, but that’s not always possible. But regardless of whether you’re hosting on-prem or in a cloud provider, Kubernetes requires solid knowledge across several areas, including networking, storage administration, systems administration, and CI/CD, not to mention the development skills needed for containerization.

I think Joey downplays the skill level required, but I don’t want to err in the opposite direction by overstating the challenge. But if you want anything beyond the bog-standard deployment of AKS/EKS, the “You must be this tall to ride the ride” sign is significantly higher than using other containerized solutions like Azure Application Services/Container Apps or Elastic Container Service.

Comments closed

Secrets Management in Kubernetes

Published 2025-08-25 by Kevin Feasel

Anshika Varshney takes us through some secrets management:

Secret management is a critical part of working with Kubernetes. When working with Kubernetes, you’ll often need to store and use sensitive information — like database passwords, API keys, and certificates. That’s where Kubernetes Secrets come in. But here’s the thing: while Kubernetes provides a way to store secrets, using them incorrectly can still expose your sensitive data.

This blog will walk you through:

  • What Kubernetes Secrets are
  • How they work
  • Common mistakes (the wrong way)
  • Best practices (the right way)
  • Real-life examples and configurations

Read on for the full article. I do want to iterate what I consider the most important of Anshika’s points: these things should never go into source control. The problem is, source control history is a lot more permanent than people customarily think about, so if you accidentally checked in a password in a config file somewhere, then got rid of the line with the password in it, a bad person with access to your source control can still look at history and find that password. The mechanism to rewrite Git history to remove a line’s existence is purposefully difficult, so a lot of developers don’t even know that it’s possible. But even then, if you’re hosting on someplace like GitHub and forks are enabled, rewriting history in your fork doesn’t rewrite it in somebody else’s fork, so again, a bad person with a fork from the right time frame could still see your exposed password.

The only fix is to cycle credentials if you ever do accidentally expose a password or key in source control files.

Comments closed

Securing PostgreSQL Containers

Published 2025-08-15 by Kevin Feasel

Mercy Bassey grabs a certificate:

Running Postgres in Docker is great for a quick test but what if you want it to behave like a proper, production-style setup with SSL encryption, certificate-based authentication, persistent volumes, and custom configurations? In this article, we’ll find out how, tackling the various tasks involved such as:

  • Generating and using self-signed SSL certificates with Postgres.
  • Setting up a PostgreSQL Docker container that uses those certs for encrypted client connections.
  • Configuring authentication for both automated services and human users.
  • Controling the behavior of your Postgres instance using mounted config files.

Read on to see how.

Comments closed

First Thoughts on Rancher Desktop

Published 2025-06-17 by Kevin Feasel

Steve Jones tries something new:

I’ve been very happy with Docker Desktop for years, running it on both laptop and desktop. However, a corporate decision was made to move to Rancher Desktop, so I now have an unexpected “opportunity” to learn something new.

Here’s a short post on how things went on the desktop and laptop.

I’m guessing corporate made the switch because of Docker for Desktop’s licensing costs. It is kind of funny how, in the Windows and even MacOS world, “Docker” is synonymous with “container,” whereas in the Linux world, that’s not at all the case.

Comments closed