Hey everyone! 👋 I recently went through a classic "it works on my machine" scenario... except my machine was the Azure Cloud Shell, and it didn't work. Here’s a quick story of how I hit a Docker wall and used native Azure tools to successfully deploy my static fashion site to Azure Container Instances (ACI).
Let's rewind. I was logged into the Azure Portal, staring at my resource group, ready to deploy my static site. My plan was simple: use the Azure Cloud Shell to run a quick docker build and docker push.
I clicked that little >_ icon in the portal's header and got to work. Little did I know, I was about to hit a classic "gotcha" and find an even better solution.
Here's how it went down.
Spoiler: It involves az acr build and a triumphant fist pump. ✊
The Goal: Simple Static Site in the Cloud
I needed to get a simple static site (HTML + CSS) for Lyzola Fashion House up and running quickly.
My go-to plan:
Write a Dockerfile (using NGINX)
Build the image
Push to Azure Container Registry (ACR)
Deploy to Azure Container Instances (ACI)
Simple, right? Well...
Here's how it went down.
🎬 Act 1: Building from the Ground Up in the Shell
The Azure Cloud Shell became my entire workspace. No fancy IDEs, no local file uploads—just a pure, classic terminal experience. Here’s how I built my project from scratch, right there in the browser:
I created a project directory and moved into it:
mkdir lyzola-fashion
cd lyzola-fashion
I wrote my index.html file using nano: nano index.html
I pasted in my HTML code, saved the file (Ctrl+O, Enter), and exited (Ctrl+X).
I created a css directory and a stylesheet:
mkdir css
nano css/style.css
Added my styles, saved, and exited.
Finally, I crafted my Dockerfile the same way:
nano Dockerfile
I typed it out line by line, saved it, and was ready to go.
Feeling confident with my files created the old-school way, I ran the classic command to build my image:
docker build -t lyzolaregistry.azurecr.io/lyzola:v1 .
And then, the moment of truth... or error.
ERROR: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
Wait, what? The Cloud Shell doesn’t have a Docker daemon? I was stunned. My entire plan, built on those carefully crafted files, was suddenly dead in the water. My two-minute deployment had just evaporated.
💡 Act 2: The "Aha!" Moment with ACR Tasks
Sitting in the Cloud Shell, surrounded by the files I just created with nano, I had to pivot. I couldn't build locally, but I was already in the cloud. That's when I remembered Azure Container Registry Tasks.
Instead of fighting the environment, I used a tool designed for it. The az acr build command uses the contents of the current directory and offloads the build process to Azure itself. No Docker on the client needed!
From the same /lyzola-fashion directory in my Cloud Shell, I ran:
az acr build --registry lyzolaregistry --image lyzola:v1 .
The logs streamed back to my console just like a local build, but the heavy lifting was happening securely in my ACR. It took the local files I had just written and built them in the cloud. Problem solved!
🚀 Act 3: Deploying from the Cloud Shell
With the image built and snugly stored in my registry, the rest was smooth sailing. Still in my trusted Cloud Shell, I deployed it to Azure Container Instances (ACI) with one command:
az container create \
--resource-group myResourceGroup \
--name lyzola-container \
--image lyzolaregistry.azurecr.io/lyzola:v1 \
--dns-name-label lyzola-unique-dns \
--ports 80 \
--registry-login-server lyzolaregistry.azurecr.io \
--registry-username $REGISTRY_USERNAME \
--registry-password $REGISTRY_PASSWORD
Initially, an error popped up, showing "subscription not registered to use namespace 'Microsoft.ContainerRegistry'. "
This was corrected by registering the subscription
Confirm registration
Then I ran the create command again with success, as seen below:
az container create \
--resource-group lyzola-rg \
--name lyzola-aci \
--image lyzolaregistry.azurecr.io/lyzola:v4 \
--cpu 1 --memory 1 \
--registry-login-server lyzolaregistry.azurecr.io \
--registry-username $REGISTRY_USER \
--registry-password $REGISTRY_PASSWORD \
--ports 80 \
--dns-name-label lyzola-aci-demo-${RANDOM} \
--os-type Linux
Added randomness for uniqueness
The critical flag here is --dns-name-label, which gives your container a public-facing URL under the azurecontainer.io domain.
A quick follow-up command to get my URL:
az container show --name lyzola-container --resource-group myResourceGroup --query ipAddress.fqdn -o tsv
The Deployment: Getting it Live on ACI
I copied the output URL, pasted it into a new tab, and there it was:
My site, built from the ground up in a terminal, now live on the internet! All without ever needing Docker on my local machine or in the Cloud Shell.
🧹 Step 5: Cleanup Duty
Being a good DevOps citizen, I cleaned up my mess:
az container delete \
--resource-group lyzola-rg \
--name lyzola-aci \
--yes
Cloud Shell threw an authentication tantrum:
Timeout waiting for token...
Solution: log back in interactively.
az login --scope https://management.core.windows.net//.default
Once I re-authenticated with the device code, deletion worked. Then I wiped my local files too:
rm -rf lyzola-fashion Dockerfile index.html
Fresh slate, happy engineer 😎.
✅ Key Takeaways
You Can Build Anything in a Shell: You don't need an IDE or a complex setup. A terminal, nano, and your knowledge are enough to get started.
Cloud Shell ≠ Docker Host: It's a common misconception. The Cloud Shell is for managing Azure resources, not for running Docker daemons.
Embrace Cloud-Native Workflows: When you hit a wall, there's often a better, integrated way. az acr build is a perfect example—it uses your local context (the current directory) but executes the build in the cloud, which is more secure and doesn't tie up your local machine.
The Power of the Integrated Shell: This entire process—from writing code in nano to a successful deployment—happened in a single browser tab. The power of cloud tooling is incredible.
The next time you're in the Azure Portal and need to get something done, let the Cloud Shell be your starting point. You might be surprised at what you can accomplish without ever leaving your browser.
A single command handled the build and push seamlessly:
Azure Cloud Shell ≠ Docker Host: You can't run docker build or docker run there. It's a common gotcha.
Use az acr build: For a seamless, authenticated, and daemon-less build and push experience directly to your Azure Container Registry.
Don't forget the --dns-name-label: This is the easiest way to get a public URL for your Azure Container Instance. Make it unique or use a trick like $RANDOM.
The Azure CLI is your friend: Everything from build to deploy can be done in a few commands, making it perfect for automation scripts.
This whole process is a great example of using cloud-native tools to simplify your workflow and get around common hurdles.
Have you run into the Docker daemon issue in Cloud Shell? How do you handle your container builds? Let me know in the comments