Application-Specific Docker Images (ASDI)
Lightweight Automation for IT Ops
DOCKER
Jack Jalali
4/27/20252 min read
In this post I present a framework for creating and deploying Application Specific Docker Images or ASDIs. These lightweight, nimble containers are the Swiss Army knives of automated deployments.
What Are ASDI?
Application-Specific Docker Images (ASDI) are purpose-built Docker images that perform one specific task—and perform it well. Think of them as minimal, mission-focused agents. Whether you're pushing updates, deploying virtual machines, replacing endpoint software, or cleaning up old agents, ASDIs are ideal for executing operations with precision and portability.
They’re especially powerful in hybrid environments where automation tools like Ansible or Terraform are used to deploy tasks on multiple virtual machines. And because they can be triggered from simple Linux shell scripts or scheduled with cron jobs, they seamlessly integrate into your existing workflow.
From creation to deployment
The operation starts by creating a custom ASDI on a secure Ubuntu-based "imager". This system runs Docker and Ansible-vault. Ansible’s role here is to encrypt any YAML files or other configs containing sensitive data.
Once the image is prepped and tested, it’s migrated to a separate deployment server, another Ubuntu server that acts as the mission execution hub. At this stage, the imager VM is powered down, effectively sealing off the version control and build environment from the rest of the network—boosting security and reducing attack surface.
Execution: Running ASDI in the Field
On the deployment server, all scripts follow a standard structure, no matter the task. Here's a typical command structure:
sudo docker run --name container-name -itd docker-image
sudo docker exec -w working-dir container-name ansible-playbook payload-playbook.yml
sudo docker stop container-name
sudo docker rm container-name
for more complex tasks where some variables cannot be baked into the docker image, we can share a volume between the host and the container. This allows us to modify the list of target virtual machines for each run and to make sure that the latest versions of files and executables are sent to the container to be executed without rebuilding the entire image
sudo docker run --name container-name -itd -v host-directory:container-directory docker-image
sudo docker exec -w working-dir container-name ansible-playbook payload-playbook.yml > ./logs/logs.log
sudo docker stop container-name
sudo docker rm container-name
in the above example, the inventory file, inventory.ini, logs folder and the executable files are shared with the container. This way we can even access the logs directly from the host without a need to interact with the container.
This three-phase process:
Deploys the container from the image
Executes the payload
Cleans up by stopping and removing the container
It’s clean, repeatable, and doesn’t leave clutter behind.
Why This Approach makes sense
Security: The imaging server is offline after build.
Flexibility: Tasks can be modified by simply updating scripts or payloads.
Consistency: Each ASDI operates predictably and identically every time.
Portability: Run the same image anywhere Docker is supported.
In a nutshell, ASDIs are a powerful strategy to deliver automation with discipline. They embody the mantra: do one thing and do it well.
In the next post I’ll outline a number of practical examples using ASDIs.
