svnscha - devops

How to: Use Docker Remote Contexts with SSH

2025-10-10T00:00:00+00:00

The Problem: When Your Laptop Becomes a Jet Engine

Working on resource-intensive Docker projects often turns laptops into jet engines. The fans spin up, the CPU overheats, and performance degrades significantly. This is especially problematic when working with limited resources - lightweight laptops, VDI sessions, or simply wanting to preserve your hardware.

An SSH-based Docker context keeps the development tools on your local machine while running Docker workloads on a more capable remote host. Your laptop stays responsive and the remote system handles the heavier work.

Step 1: Prerequisites

Before we start, ensure you have:

SSH access configured to your remote Docker host with a proper SSH config entry like:

# ~/.ssh/config
Host docker-remote
  HostName 10.10.10.10
  IdentityFile ~/.ssh/id_rsa
  User ubuntu

Your user is in the docker group on the remote host:

sudo usermod -aG docker $USER

That's all the setup needed! Now let's create the Docker context.

Step 2: Create the SSH-Based Docker Context

Creating the Docker context is incredibly simple when you have SSH properly configured.

Create Your SSH-Based Remote Context

Create a new context using your SSH config host:

docker context create docker-remote --docker host=ssh://docker-remote

That's it! Docker will use your existing SSH configuration, including the hostname, user, and identity file you've already set up.

The beauty of this approach: No daemon.json changes, no TCP configuration, no port forwarding, no firewall rules, no TLS certificate generation - just leverage your existing SSH security infrastructure. Simple and elegant!

Check Your Current Contexts

First, let's see what contexts you currently have:

docker context ls

You'll probably see something like:

NAME              DESCRIPTION                               DOCKER ENDPOINT
default *         Current DOCKER_HOST based configuration   npipe:////./pipe/docker_engine
desktop-linux     Docker Desktop                            npipe:////./pipe/dockerDesktopLinuxEngine
desktop-windows   Docker Desktop                            npipe:////./pipe/dockerDesktopWindowsEngine
docker-remote                                               ssh://docker-remote

Test the Connection

Let's verify everything works:

docker --context docker-remote container ls

If you see your remote containers listed (or an empty list if none are running), congratulations! You're successfully connected to your remote Docker host via SSH.

Step 3: Make It Your Default (Optional)

If you want to use the remote context by default, you can switch to it:

docker context use docker-remote

Now all your docker commands will automatically use the remote host:

docker container ls
# This now runs on your remote host!

Environment Variable Override

For more granular control, you can also use the DOCKER_CONTEXT environment variable:

# Windows PowerShell
$env:DOCKER_CONTEXT = "docker-remote"

# Linux/macOS
export DOCKER_CONTEXT=docker-remote

This approach is particularly useful in CI/CD scenarios or when you want different shells to use different contexts.

Why SSH is Better

Using SSH for Docker remote contexts offers several advantages over TCP:

Security: All communication is encrypted by default
Authentication: Leverages existing SSH keys and authentication methods
No daemon configuration: No need to modify Docker daemon settings on the remote host
Firewall friendly: Uses standard SSH port (22)
Audit trail: SSH logging provides better security monitoring

Switching Between Contexts

Need to switch back to local Docker for something? Easy:

# List available contexts
docker context ls

# Switch to local Docker
docker context use default

# Or use a specific context for one command
docker --context default container ls

Bonus: PowerShell Function for Quick Context Switching

Here's a handy PowerShell function to make switching contexts even easier. Add this to your PowerShell profile for instant remote Docker activation:

Edit Your PowerShell Profile

First, open your PowerShell profile for editing:

notepad $PROFILE

If the file doesn't exist yet, PowerShell will ask if you want to create it - say yes.

Add the Function

Add this function to your profile:

function docker-remote-activate {
    $env:DOCKER_CONTEXT = "docker-remote"
    Write-Host "Docker context switched to remote host"
}

Replace "docker-remote" with whatever you named your remote context.

Save and Reload

Save the file and reload your PowerShell profile:

. $PROFILE

Usage

Now you can instantly activate remote Docker in any PowerShell session:

# Activate remote Docker for this session only
docker-remote-activate

# Now all Docker commands run remotely
docker ps
docker images
docker build .

The beauty of this approach is that it only affects the current PowerShell session - open a new terminal window and you're back to local Docker by default!

Global vs Terminal-Specific Context Switching

You have two ways to switch between local and remote Docker contexts:

Global Context Switching

Affects all terminals system-wide:

# Switch globally to remote
docker context use docker-remote

# Switch back to local
docker context use default

Terminal-Specific Context

Affects only the current terminal session:

# Terminal 1: Remote context
docker-remote-activate
docker ps  # runs remotely

# Terminal 2: Still local context  
docker ps  # runs locally

Whether you prefer global context switching or terminal-specific control, Docker remote contexts give you the flexibility to work exactly how you want.

Summary

Using SSH-based Docker remote contexts provides a secure, simple solution for offloading resource-intensive Docker operations to remote hosts. With just a single command and proper SSH configuration, you can transform your development workflow without compromising security.

The SSH approach eliminates the complexity of daemon configuration while providing enterprise-grade security through encrypted communication and existing authentication infrastructure.

Key Benefits:

Secure by default (encrypted communication)
No daemon configuration required
Uses standard SSH authentication
Works with existing SSH infrastructure
Simple one-command setup

References:

Simplify Elasticsearch and Kibana Installation

2024-04-24T00:00:00+00:00

Why, You Ask?

Setting up Elasticsearch and Kibana involves the same steps each time: update the system, configure repositories, install packages, and apply the initial configuration. I wrote a script to automate that work and make the setup reusable.

It's time-consuming and frustrating. I'm tired of it.

Automating the Setup

This Bash script installs Elasticsearch and Kibana as a single-node cluster. I use it when I need a small, repeatable setup without adding another configuration tool.

Why Choose a Bash Script?

I chose Bash instead of Ansible because the script also works well with cloud-init and inside Docker environments. It has no extra tooling requirements and is easy to copy to a new machine.

Building the Script: A Step-by-Step Guide

Let's walk through the crafting of the script that automates setting up Elasticsearch and Kibana. Here's how I pieced it together, one step at a time:

Checking for Superuser Privileges The script needs administrative access, so it starts by checking for root privileges.

if [ "$(id -u)" != "0" ]; then
   echo "This script must be run as root" 1>&2
   exit 1
fi

Updating the System and Installing Essential Packages Updating the system first helps avoid installation problems caused by outdated packages.

apt update
apt install -y apt-transport-https gnupg curl jq

Adding the Elasticsearch Repository Getting this right is like picking the perfect ingredients for a master chef recipe - it ensures the rest of the meal turns out just right.
Installing Elasticsearch and Kibana Next, the script installs Elasticsearch and Kibana.
Configuring and Starting Services The plot thickens! Setting up the services and getting them running is like reaching the climax of our story - where all elements come together to unveil the full potential of our setup.

Rather than churn out another cookie-cutter guide on setting up Elasticsearch and Kibana, you can view the complete script here. However, I do want to emphasize the initial configuration process involving enrollment tokens and security settings. I've automated these aspects because, let's face it, I've read too many guides that suggest just turning off security for the sake of simplicity. That's not my style - I'd rather keep things secure automatically. It's not rocket science, but it sure is critical. Why simplify by compromising security when you can automate it effectively, right?

This approach ensures you get the functionality you need without the hassle of manual setup or the risks of disabled security.

Perfecting the Automation: Securing and Finalizing the Setup

The final part configures security and leaves both services ready to use.

Broadcasting the Good News First things first, let's make sure any user logging into the system knows what's been accomplished:

echo -e "=== init-vm.sh: Initial ===" >> /etc/motd
echo -e "[> Elasticsearch 'elastic' password: $ELASTIC_PASSWORD" >> /etc/motd
echo -e "[> Test instance with 'curl -k -X GET https://elastic:$ELASTIC_PASSWORD@localhost:9200'" >> /etc/motd
echo -e "=== init-vm.sh: Get started ===" >> /etc/motd
echo -e "[> Reset 'elastic' password with '/usr/share/elasticsearch/bin/elasticsearch-reset-password -u elastic'." >> /etc/motd

Here, we're updating the message of the day (MOTD) file to ensure anyone who logs in is immediately informed about how to interact with Elasticsearch and what steps to take next. It's like leaving a note on the fridge - impossible to ignore and incredibly helpful.

Decoding the Secrets Automation isn't just about doing things without human intervention; it's also about doing them securely and wisely:

# Because who likes doing setup manually, right?
decoded_token=$(echo $KIBANA_ENROLLMENT_TOKEN | base64 --decode)
address=$(echo $decoded_token | jq -r '.adr[0]')
fingerprint=$(echo $decoded_token | jq -r '.fgr')
api_key=$(echo $decoded_token | jq -r '.key')

Decoding the enrollment token reveals the essential elements needed to securely configure Kibana: the address, fingerprint, and API key.

Harnessing Version and Build Information Knowing exactly which version and build of Kibana you're working with is required for the API, so let's get that:

ver=$(jq -r '.version' /usr/share/kibana/package.json)
build=$(jq -r '.build.number' /usr/share/kibana/package.json)

Re-encoding and Verification Secrecy is paramount, and so is verification. Here's how we handle both:

encoded_api_key=$(echo -n $api_key | base64)
output=$(sudo /usr/share/kibana/bin/kibana-verification-code)
verification_code=$(echo $output | awk -F": " '{print $2}' | sed 's/ //g')

The API key needs to be re-encoded to maintain security, and we also extract a verification code necessary for the next step - enrolling Kibana.

The Final Act: Enrolling Kibana

And now, the final piece of our automation puzzle:

curl -k -v -X POST "http://localhost:5601/internal/interactive_setup/enroll" \
     -H "Accept: */*" \
     -H "Content-Type: application/json" \
     -H "Host: localhost:5601" \
     -H "Origin: http://localhost:5601" \
     -H "Referer: http://localhost:5601/" \
     -H "kbn-build-number: $build" \
     -H "kbn-version: $ver" \
     -H "x-elastic-internal-origin: Kibana" \
     -H "x-kbn-context: %7B%22type%22%3A%22application%22%2C%22name%22%3A%22interactiveSetup%22%2C%22url%22%3A%22%2F%22%7D" \
     -d '{"hosts":["https://'$address'"],"apiKey":"'$encoded_api_key'","caFingerprint":"'$fingerprint'","code":"'$verification_code'"}'

This curl command not only sends all the needed parameters to Kibana for configuration but also uses the verification code to ensure that the setup is both authorized and secure. It's akin to dotting the i's and crossing the t's in our setup script.

Summary

The script turns a fresh system into a secured, working Elasticsearch and Kibana installation. Feel free to adapt it to your own environment.

Check out the complete script here:

init-elastic-search-kibana-vm.sh

Happy automating, and here's to many insightful data explorations!

P.S.: This script is tailored for automating development environments. Remember, a single-node cluster isn’t suited for production use, and storing passwords in the message of the day (MOTD) file? That’s a no-go for serious deployments. 😏