Type your search keyword, and press enter

How to run an ssh server on kubernetes

Let’s say you’d like to run a pod on your cluster that accepts incoming ssh connections. (There are various reasons to do this — I have one application planned for an upcoming post.)

It’s actually quite easy to just run sshd in a container and mount a public key file as /root/.ssh/authorized_keys to allow a user with the corresponding private key to ssh in as root.

It’s a little trickier, though, if you want to allow ssh access without allowing root access.

The main issue is that a non-root user can’t launch the ssh service, so you can’t simply run your pod as a non-root user. And [right now, as far as I know] you can’t mount a file with a different owner than the security context of the pod. But the ~/.ssh/authorized_keys file needs to be owned by its own corresponding user in order for the ssh service to accept it…

Continue reading… “How to run an ssh server on kubernetes”

How to move a WordPress blog to kubernetes

WordPress has been a popular blogging/website platform for decades, which means that there are a quite a number of old WordPress-based websites out there. But if you’re hosting one on a VM, it can be difficult to scale it, to maintain it, and to update the look without breaking it. Kubernetes to the rescue!

Cloud Native best practices recommend a clean separation among executable code (in the container), configuration (in the kubernetes manifests), and data (in the database and/or mounted volumes). But WordPress was first designed before the widespread use of containers — so, unfortunately, the code, configuration, and content data are all jumbled together in the filesystem.

Ultimately deploying WordPress on kubernetes is quite doable — and enforcing the separation of components (code/configuration/data) makes it easy to deploy as many copies as you like, which simplifies maintenance and scaling (compared to running it on a VM). But the standard WordPress docker images need to employ some ugly hackery to get the code and configuration into a writable volume for it to work — so the initial setup can be delicate.

If you would like to migrate an existing WordPress blog/site to kubernetes, you will need the following:

Continue reading… “How to move a WordPress blog to kubernetes”

startup2scalable.com is open for business!!

When I was the tech lead for DevOps and Cloud Infrastructure at South Pole, I liked to think of all of the various dev teams as my clients. Marketing websites, machine learning projects, data pipelines, and all manner of applications for internal and external clients — the teams doing these projects all needed cloud infrastructure and a bit of help getting set up.

My objective was to design a system of ci/cd pipelines and kubernetes objects that was simple and flexible enough for the developers to understand (without too much extra effort) so that the teams could manage and customize their own releases and deployments — with as much (or as little) ongoing help from me as they wanted.

Now I’m ready to offer the same service to the rest of the world!

Continue reading… “startup2scalable.com is open for business!!”

Read-write-many volumes on LKE with NFS

When deciding whether to use Linode as my kubernetes provider, I needed to ensure that I would have read-write-many volumes available for deployments that need them. So I did a quick search, and the only thing that came up was this guide on setting them up with rook — which is deprecated. Not cool.

On other cloud providers, I created read-write-many volumes using a Network File System — so I wondered if I could do the same on Linode. Answer: yes. And it’s actually pretty easy and works well. Here’s how:

Continue reading… “Read-write-many volumes on LKE with NFS”

Let’s Get Real about Disruption

This article is an adaptation of the talk I gave at the EIT Climate KIC Community Summit in Hamburg (July 2019)

Here’s a parable you’ve probably heard:

In the 1890s New York City had a daunting horse manure problem. Transporting people and goods around the city resulted in so much manure that officials worried that the streets would soon be buried deep in it. Apparently in 1898 there was a conference to address the problem in which they essentially gave up.

Continue reading… “Let’s Get Real about Disruption”

How and Why to Build your IT Career through Startups

startup_house

I’ve spent most of my career working for tech startups, but I don’t consider myself an entrepreneur. It was kind of by chance that I’ve ended up working more for small and new tech companies rather than big, established ones — and consequently, I’ve learned that choosing this career path offers some real advantages.

If you are an engineer, should you do the same? Let me give you an overview of some of the pros and cons. The short version is the following: It’s more work, more stress, and more varied tasks for less pay — but rising to great challenges means gaining great experience.

Continue reading… “How and Why to Build your IT Career through Startups”

Growing from Startup to Scalable: Make the Right Changes at the Right Time

Early in my career I was working for a tech firm that had recently grown from a tiny startup to a company with a few hundred employees. One day the CEO gave a company-wide address in which he explained, “Startups produce code more efficiently than large companies — therefore we will continue to run this company like a startup!”

Unfortunately, in practice, this essentially amounted to free soft-drinks and everyone being expected to work unpaid overtime every day.

I remember at the time thinking, “That’s not how it works. There are reasons a big company can’t function like a startup.” And if you figure in all of startups that fail, it’s not even clear that startups produce more code-in-production per developer than larger companies.

In retrospect, I view that boss’s silly speech as a gift. It has inspired me, as I’ve worked at different companies over the years, to observe carefully the ways that “startup mode” differs from scalable practices — and to think about the best strategies for getting from one to the other.

Continue reading… “Growing from Startup to Scalable: Make the Right Changes at the Right Time”

The Perils of Adding Layers of Management

 

If you’re the CEO of a hip, young startup, you naturally want to be the cool, approachable boss — not the one who distances himself from his employees with ten levels of hierarchy by adding a bunch of extra bosses who are just there to tell other people what to do. It’s tempting to dismiss management as a useless task and try to keep your organigram flat forever.

In tech companies in particular, there’s a common misconception that management is “easier” than engineering.

It’s not hard to see where this idea comes from. Typically engineers will spend years getting an advanced degree — or creating an amazing independent project — in order to qualify for a software engineering job. And then someone on the team gets promoted to head the team, usually without any management training of any kind.

But treating management as easier (or as not really a task at all) can lead to some costly errors. I was once on a team where the least-performing engineer got tapped to manage the team. Apparently the idea was that if he’s struggling with coding, maybe he can at least organize the meetings and put the status updates into the project planning software. And that might have worked out if those were the hardest tasks of the job.

Even worse (and more common) is to tap the most productive engineer to be the team lead. The reasoning seems to go like this: “He’s so good at this — he should be telling all of the other engineers what to do,” and/or “With such a brilliant engineering mind, management tasks should be trivial for him!”

Continue reading… “The Perils of Adding Layers of Management”

Disruptive Tech Management

disrupt_tech_managementIn our modern tech world, the holy grail is to come up with a new idea or develop new technology that is such a game-changer that it “disrupts” an existing industry. If you want attention, success, and respect in this industry, disruption is the way to go.

But what if you’re in tech management? There’s a temptation to feel like you need to disrupt there too — come up with a game-changing playbook — in order to be on the cutting edge. But while our ever-changing tech landscape naturally leaves doors wide open for new ideas, there’s less reason to imagine that the task of organising a team of engineers to construct something should change dramatically from one decade to the next. So maybe we should consider trying out some old-school ideas.

One of the key components of Scrum and other modern management playbooks is the idea that the team should manage itself. As I explained in my previous article, the tech industry has a huge problem with undervaluing management skills — indeed treating management as though it’s not even a task and doesn’t require skill and expertise. I think the idea of “self-managing teams” is the fruit of that misconception.

If your company needs a custom internal app, you’re not going to make a committee of the accountant, the communications director, and the lawyer, give them a weekend course in design patterns, and tell them to go to it — even if they’re the ones who are going to use the app. You would hire an engineer. Even for a task that requires less specific training than programming an app (say, writing the content of your company’s brochure), you would give that task to someone who is qualified to do it.

Now, if you take a team of engineers — all of whom were hired specifically for their engineering skills — there is no particular reason to believe anyone on that team is qualified to manage it. Chances are that there’s at least one person on the team who is not qualified to be managing other people and projects — so making them all manage together as a committee doesn’t really help. The only way this idea makes any sense is if you believe that management does not require any skills.

Continue reading… “Disruptive Tech Management”