Our target environment is a single t2.small EC2 instance (2 GB RAM, 1 vCPU, ~$15/month) running Ubuntu 18.04. We will use KIND (Kubernetes IN Docker) to run the cluster, add cert-manager and nginx-ingress for TLS and routing, and finish by deploying HackMD — an open-source collaborative Markdown editor — as a proof of concept.

Set Up a Machine

These instructions target AWS EC2, but the same approach works on any cloud provider or bare-metal host that can run Docker.

Launch the Instance

1. Open the EC2 console and click Launch Instance.
2. Choose Ubuntu Server 18.04 LTS as the AMI.
3. Select the t2.small instance type. Do not go smaller — Kubernetes has significant baseline memory overhead. If you plan to run memory-hungry workloads (databases, CI runners, etc.) consider t2.medium or larger.
4. Increase the root volume from the default if you intend to store significant data on the node.
5. In the security group, open port 22 (SSH), port 80 (HTTP), and port 443 (HTTPS).
6. Download and store your SSH key pair safely.

Assign an Elastic IP

EC2 instances get a new public IP every time they restart. An Elastic IP gives your instance a stable address that you can map to a DNS name.

1. In the EC2 console, go to Elastic IPs → Allocate Elastic IP address.
2. Associate the new address with your new instance.

Create DNS Records

Head to Route 53 (or your DNS provider) and create two A records:

• *.example.com → your Elastic IP (wildcard record covers every subdomain)
• example.com → your Elastic IP (optional, for the apex domain)

With DNS in place, every subdomain you configure on the cluster will automatically resolve to your server.

Install Dependencies

SSH into your instance, then install the following tools in order.

Docker

KIND runs Kubernetes inside Docker containers, so Docker is the foundational dependency.

sudo apt update
sudo apt install -y apt-transport-https ca-certificates curl software-properties-common
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu bionic stable"
sudo apt update
sudo apt install -y docker-ce
sudo usermod -aG docker $USER
newgrp docker

KIND

KIND (Kubernetes IN Docker) creates a fully functional Kubernetes cluster using Docker containers as nodes. This is ideal for a single-machine setup.

curl -Lo ./kind https://github.com/kubernetes-sigs/kind/releases/download/v0.5.1/kind-$(uname)-amd64
chmod +x ./kind
sudo mv ./kind /usr/local/bin/kind

kubectl

kubectl is the primary CLI for communicating with any Kubernetes cluster. It reads your kubeconfig to know which cluster to talk to.

curl -LO "https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl"
chmod +x ./kubectl
sudo mv ./kubectl /usr/local/bin/kubectl

Helm

Helm is the package manager for Kubernetes. Helm charts package up all the manifests needed to deploy an application (WordPress, Ghost, MySQL, GitLab, etc.) into a single, versioned, configurable unit.

sudo snap install helm --classic

Reckoner

Reckoner is a Python tool that lets you declare multiple Helm releases in a single YAML file (called a course file), making it easier to manage several charts together with shared configuration and install hooks.

sudo apt-get install -y python3 python3-pip
export PATH=$PATH:~/.local/bin/
pip3 install reckoner

Dependency Summary

• Docker — runs isolated containers (and hosts the KIND cluster nodes).
• KIND — bootstraps a Kubernetes control plane and worker node inside Docker.
• kubectl — CLI for managing Kubernetes resources.
• Helm — installs and upgrades packaged Kubernetes applications.
• Reckoner — manages multiple Helm charts declaratively from a single YAML file.

Build the Cluster

Create a file called cluster.yaml. Storing this in version control is strongly recommended — it is a complete description of your cluster topology.

cluster.yaml

kind: Cluster
apiVersion: kind.sigs.k8s.io/v1alpha3
nodes:
- role: control-plane
- role: worker
  extraMounts:
  - containerPath: /opt/local-path-provisioner
    hostPath: /home/ubuntu/kind-disk
  extraPortMappings:
  - containerPort: 80
    hostPort: 80
    listenAddress: "0.0.0.0"
  - containerPort: 443
    hostPort: 443
    listenAddress: "0.0.0.0"

Key decisions in this config:

• Two roles — a control-plane node runs the Kubernetes API server, scheduler, and controller manager; the worker node runs your application pods.
• Persistent storage mount — /home/ubuntu/kind-disk on the host is mounted into the worker container so database volumes survive pod restarts. Adjust this path to suit your environment.
• Port mappings — ports 80 and 443 are forwarded from the host into the worker container so external HTTP/HTTPS traffic reaches the cluster.

Create the cluster and point kubectl at it:

kind create cluster --config cluster.yaml
export KUBECONFIG="$(kind get kubeconfig-path --name='kind')"

Verify both nodes are ready (this can take a minute or two):

kubectl get nodes

Expected output:

NAME                 STATUS   ROLES    AGE    VERSION
kind-control-plane   Ready    master   109s   v1.15.3
kind-worker          Ready    <none>   73s    v1.15.3

Configure the Cluster

Install Tiller (Helm’s In-Cluster Component)

Helm 2 requires a server-side component called Tiller. We create a dedicated namespace and give it cluster-admin privileges via RBAC.

tiller.rbac.yaml

apiVersion: v1
kind: Namespace
metadata:
  name: tiller
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: tiller
  namespace: tiller
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: tiller-clusterrolebinding
subjects:
- kind: ServiceAccount
  name: tiller
  namespace: tiller
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: ""

kubectl apply -f tiller.rbac.yaml
export TILLER_NAMESPACE=tiller
helm init --service-account tiller

Configure Persistent Storage

KIND ships with a default standard storage class that does not persist data across container restarts. We replace it with Rancher’s local-path-provisioner, which writes data to the host directory we mounted in cluster.yaml.

# Install the local-path-provisioner
kubectl apply -f https://raw.githubusercontent.com/rancher/local-path-provisioner/master/deploy/local-path-storage.yaml

# Remove the default flag from the built-in 'standard' storage class
kubectl patch storageclass standard -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"false", "storageclass.beta.kubernetes.io/is-default-class":"false"}}}'

# Make local-path the new default
kubectl patch storageclass local-path -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true", "storageclass.beta.kubernetes.io/is-default-class":"true"}}}'

Install cert-manager and nginx-ingress

These two components handle the two things every public web service needs: TLS certificates and HTTP routing.

• cert-manager — automatically provisions and renews TLS certificates from Let’s Encrypt.
• nginx-ingress — proxies incoming HTTP/HTTPS requests to the correct Kubernetes service based on the hostname.

First, create issuer.yaml to tell cert-manager to use the Let’s Encrypt ACME v2 API. Replace you@example.com with your real email address (Let’s Encrypt uses it for expiry notices).

issuer.yaml

apiVersion: cert-manager.io/v1alpha2
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: you@example.com
    privateKeySecretRef:
      name: letsencrypt-prod
    solvers:
    - http01:
        ingress:
          class: nginx

Do not apply this manifest yet — cert-manager’s CRDs must exist first. Next, create core.course.yaml for Reckoner. The post_install hook on cert-manager applies issuer.yaml automatically after the chart is ready.

core.course.yaml

repositories:
  jetstack:
    url: https://charts.jetstack.io
namespace: default
charts:
  cert-manager:
    hooks:
      pre_install:
      - kubectl apply --validate=false -f https://raw.githubusercontent.com/jetstack/cert-manager/release-0.11/deploy/manifests/00-crds.yaml
      post_install:
      - sleep 30 && kubectl apply -f issuer.yaml
    namespace: cert-manager
    repository: jetstack
  nginx-ingress:
    namespace: nginx-ingress
    values:
      controller:
        hostNetwork: true
        service:
          type: LoadBalancer

Run Reckoner to install both charts:

reckoner plot core.course.yaml

Verify the pods are running (allow a minute or two for images to pull):

$ kubectl get pods -n nginx-ingress
NAME                                             READY   STATUS    RESTARTS   AGE
nginx-ingress-controller-664b77978-gbd59         1/1     Running   0          14s
nginx-ingress-default-backend-576b86996d-fjb4k   1/1     Running   0          14s

$ kubectl get pods -n cert-manager
NAME                                       READY   STATUS    RESTARTS   AGE
cert-manager-6b78b7c997-mblt4              1/1     Running   0          18s
cert-manager-cainjector-54c4796c5d-psdgt   1/1     Running   0          18s
cert-manager-webhook-77ccf5c8b4-8tkwt      1/1     Running   0          17s

Install an Application: HackMD

To validate the full stack, we’ll deploy HackMD (now known as CodiMD/HedgeDoc), an open-source, real-time collaborative Markdown editor. It is a lightweight, self-hosted alternative to Google Docs, and it stores all data in a PostgreSQL database that will live in your kind-disk directory.

Create the Ingress

The Ingress resource tells nginx-ingress how to route traffic for hackmd.example.com and instructs cert-manager to obtain a TLS certificate. Replace both occurrences of example.com with your real domain.

ingress.yaml

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: nginx
    cert-manager.io/cluster-issuer: letsencrypt-prod
    kubernetes.io/tls-acme: "true"
  name: hackmd
  namespace: hackmd
spec:
  rules:
    - host: hackmd.example.com
      http:
        paths:
          - backend:
              serviceName: hackmd
              servicePort: 3000
            path: /
  tls:
  - secretName: tls-prod-cert
    hosts:
    - hackmd.example.com

Create the Reckoner App Course File

Add HackMD to a separate course file for application-layer charts. As you deploy more apps, add them here.

apps.course.yaml

namespace: default
charts:
  hackmd:
    namespace: hackmd
    hooks:
      post_install:
      - kubectl apply -f ./ingress.yaml

Deploy it:

reckoner plot apps.course.yaml

After a few moments, HackMD should be accessible at https://hackmd.example.com. cert-manager will automatically obtain a Let’s Encrypt certificate. Data will be stored under /home/ubuntu/kind-disk on the host.

Adding More Applications

The pattern for every future application is the same:

1. Add a chart entry to apps.course.yaml.
2. Create a corresponding ingress.yaml pointing to your domain.
3. Run reckoner plot apps.course.yaml.

Because all your configuration lives in YAML files committed to Git, you can recreate the entire cluster — including all applications — on a new machine by replaying the same commands. This is the core value proposition of infrastructure as code at personal scale.

Summary

Running Kubernetes at personal scale adds some operational complexity, but it pays off quickly: every application you self-host follows the same installation and upgrade pattern, your infrastructure is fully version-controlled, and migrating to a larger machine requires nothing more than replaying your playbooks.

Original article sourced from containerjournal.com (2019).

Can Ansible Manage Windows Systems?

Ansible is a widely used configuration management and automation tool with deep roots in the Linux ecosystem. However, it can also target Windows hosts for configuration, provisioning, and application lifecycle management. The catch: the setup process is noticeably more complex than it is on Linux, and there are meaningful constraints on how Windows machines can participate in an Ansible environment.

How Ansible Communicates with Windows Hosts

On Linux, Ansible uses SSH to communicate with managed nodes. Because SSH is available by default on most Linux distributions, getting Ansible to control a Linux host is relatively straightforward.

Windows is different. Rather than SSH, Ansible communicates with Windows hosts over WinRM (Windows Remote Management) using PowerShell. To prepare a Windows host for Ansible management, the following minimum requirements must be met on the managed node:

• PowerShell 3.0 or higher
• .NET Framework 4.0 or higher
• WinRM configured and enabled

Ansible’s official documentation includes a ConfigureRemotingForAnsible.ps1 script that automates much of the WinRM setup on Windows managed nodes. Running this script is typically one of the first steps when onboarding a Windows host.

Where the Ansible Control Node Must Run

A critical architectural point: the Ansible control node—including Ansible Tower (now AWX/Red Hat Ansible Automation Platform)—must run on Linux. Ansible itself cannot natively execute on a Windows host as the control machine.

If your only available machine is a Windows server, you have two realistic options:

• Run a Linux virtual machine on the Windows host and use that VM as the Ansible control node.
• Use Windows Subsystem for Linux (WSL)—a Microsoft feature available since Windows 10 that allows native Linux command-line tools to run on Windows. WSL can be installed from the Microsoft Store.

It is important to note that Ansible does not officially support WSL for production use. WSL may be suitable for development, testing, or learning purposes, but relying on it in a production environment is not recommended based on Ansible’s own guidance.

What Windows Can and Cannot Do in an Ansible Environment

Understanding the role Windows can play helps set accurate expectations:

Because Python modules cannot run directly on Windows managed nodes, teams that rely heavily on Python-based Ansible modules need to account for this. A common workaround is to run those modules on the Ansible controller itself using the delegate_to: localhost directive in a playbook task.

Setting Up Ansible to Manage a Windows Host: Key Steps

Unlike Linux, where a single apt-get install ansible or dnf install ansible command gets you most of the way there, managing Windows with Ansible requires several configuration steps across both the control node and the managed Windows host.

On the Windows Managed Node

1. Verify PowerShell 3.0+ and .NET 4.0+ are installed.
2. Enable and configure WinRM (use the Ansible-provided setup script for convenience).
3. Configure firewall rules to allow WinRM traffic (typically TCP 5985 for HTTP, 5986 for HTTPS).
4. Set up an appropriate authentication method (Basic, NTLM, Kerberos, or CredSSP depending on your environment).

On the Ansible Control Node (Linux)

1. Install Ansible on your Linux control node.
2. Install the pywinrm Python library, which Ansible requires to communicate with Windows hosts over WinRM: pip install pywinrm
3. Define Windows hosts in your inventory file with the correct connection variables:

[windows]
win-server-01 ansible_host=192.168.1.10

[windows:vars]
ansible_user=Administrator
ansible_password=YourPassword
ansible_connection=winrm
ansible_winrm_transport=ntlm
ansible_winrm_server_cert_validation=ignore

Always store credentials securely using Ansible Vault rather than plaintext in inventory files.

Why Windows Teams Should Still Consider Ansible

Despite the added complexity, Ansible offers real value for organizations running Windows infrastructure:

• Unified tooling: A single configuration management platform can manage both Linux and Windows infrastructure, reducing the number of tools teams need to learn and maintain.
• Agentless architecture: Like Linux, Windows managed nodes do not require an Ansible agent installed—only WinRM must be configured.
• Rich Windows module library: Ansible ships with many Windows-specific modules covering tasks such as managing IIS, Active Directory, Windows features, registry keys, services, and software packages.
• DevOps and automation adoption: Teams can use the same playbook-based workflows for Windows application lifecycle management as they do for Linux workloads.

Summary

Ansible can absolutely be used to manage Windows systems—but Windows is strictly a managed node, not a control node. The Ansible controller must run on Linux (directly, via VM, or via WSL for non-production use). Windows managed nodes communicate via WinRM and PowerShell rather than SSH. The setup involves more steps than a typical Linux Ansible deployment, but the payoff is a unified automation platform capable of managing your entire infrastructure regardless of operating system.

Why Docker Desktop Is the Best Starting Point for macOS

macOS is a popular choice for cloud and container-based development thanks to its Unix foundation, stability, and tooling ecosystem. If you want to run Docker on a Mac, Docker Desktop is the path of least resistance. It handles the entire installation in a few clicks and sets up everything you need to start pulling images and running containers immediately.

It is worth being clear about what Docker Desktop does and does not provide:

• What it installs: the Docker daemon, the docker CLI, Docker Compose, and Docker credential helpers.
• What it adds to macOS: a menu-bar whale icon that gives quick access to preferences, sign-in to Docker Hub, and status information.
• What it does not do: provide a full Apple-native GUI for container lifecycle management out of the box. For that, a separate tool such as Kitematic (now deprecated upstream) or third-party alternatives are needed.

Prerequisites

• A supported version of macOS (check the Docker Desktop release notes for the current minimum version requirement).
• Administrator privileges on the Mac.
• A free Docker Hub account if you intend to push images or access private repositories.

Installing Docker Desktop

The installation process is straightforward:

1. Go to docker.com/products/docker-desktop and download the macOS installer (.dmg file). Choose the correct chip architecture — Apple Silicon (M1/M2/M3) or Intel — for your machine.
2. Double-click the downloaded .dmg file to mount the disk image.
3. In the installer window, drag the Docker icon into the Applications folder.
4. Open Docker from the Applications folder. macOS will prompt you for your administrator password so the Docker daemon can be installed as a system service.
5. Wait for the whale icon to appear in the menu bar and animate. Once the animation stops and the icon is steady, Docker is running.

To verify the installation, open Terminal and run:

docker --version
docker run hello-world

A successful hello-world run confirms that the daemon is reachable and images can be pulled from Docker Hub.

Working with Docker from the Command Line

Once Docker Desktop is running, every standard Docker command works in Terminal. For example, to pull and run the latest NGINX image:

# Pull the latest NGINX image
docker pull nginx

# Run NGINX, mapping port 8080 on your Mac to port 80 in the container
docker run -d -p 8080:80 --name my-nginx nginx

# Confirm the container is running
docker ps

Open a browser and navigate to http://localhost:8080 to see the NGINX welcome page served from inside the container.

GUI-Based Container Management

If you prefer a graphical interface for searching Docker Hub, launching containers, and inspecting logs, there are a couple of options:

Docker Desktop Dashboard

Modern versions of Docker Desktop ship with a built-in Dashboard that lets you view running containers, inspect logs, open a shell inside a container, and manage volumes and images — all without leaving the app. Click the Docker whale icon in the menu bar and select Dashboard to open it.

Kitematic (Legacy)

Kitematic was a standalone GUI tool for Docker that was bundled with older versions of Docker Desktop. It has since been deprecated by Docker, Inc. and is no longer actively maintained. If you are running a recent version of Docker Desktop, the built-in Dashboard covers the same use cases. If you still need Kitematic for a legacy workflow, download it directly from the GitHub releases page rather than through the Docker menu, as the menu-bar shortcut in older versions was known to produce a broken installation.

Optional: Installing Git

Most Docker-based workflows involve pulling application source code from a Git repository. If Git is not already on your Mac, the simplest installation methods are:

• Xcode Command Line Tools: Run git --version in Terminal; macOS will prompt you to install the tools if Git is missing.
• Homebrew: Run brew install git for the latest upstream version.
• Official installer: Download from git-scm.com/download/mac.

Key Takeaways

• Docker Desktop is the official, supported, and easiest way to install Docker on macOS.
• After installation, verify with docker run hello-world before starting any real work.
• Use the built-in Docker Desktop Dashboard for GUI-based container management on current versions.
• Kitematic is deprecated; rely on the Dashboard or third-party tools for GUI workflows.
• Standard docker and docker compose CLI commands work in any Terminal session once Docker Desktop is running.