My Cloud Deployment Adventure

Hey DevOps fam 👋🏾

Ever had a classic “it works on my machine” moment… except your “machine” is the Azure Cloud Shell, and suddenly… it doesn’t? 🙃 That was me last week. Let me take you on a quick adventure of hitting a Docker wall and then triumphantly deploying my static fashion site to Azure Container Instances (ACI) using native Azure tools.

The Goal: Simple Static Site, Cloud-Style

I wanted to get a quick static site (HTML + CSS) for Lyzola Fashion House live in the cloud. My plan was straightforward:

1. Write a Dockerfile using NGINX

2. Build the image

3. Push to Azure Container Registry (ACR)

4. Deploy to Azure Container Instances (ACI)

Simple, right? Well… not exactly.

So picture this: I logged into Azure Cloud Shell, feeling like a boss. You know that vibe when you’re about to flex your DevOps muscles? 💪🏾 Yeah, that one.

Cloud Shell is super convenient because you don’t even need to install the Azure CLI locally. Just pop open your browser, click on the little shell icon in the Azure portal, and boom — you’re inside a Linux environment, ready to roll

# Opened Bash in Cloud Shell
elizabeth [ ~ ]$

My mission? Deploy my little Lyzola Fashion static website inside an Azure Container Instance (ACI). Easy, right? Well… the plot thickens. 😅

---

🛠 Step 1: Building the Docker Image (or so I thought)

I had my tiny setup:

• index.html → my homepage (all pink and white ✨).

• Dockerfile → a baby one-liner to package it with Nginx.

I decided to do everything in-browser, no fancy IDEs, no local Docker installs. Just the Cloud Shell, nano, and determination.

mkdir lyzola-fashion

cd lyzola-fashion

nano index.html → my homepage (all pink and white ✨). # wrote HTML

To check the content of the index.html file, I ran the command: cat index.html

nano Dockerfile → a baby one-liner to package it with Nginx. # crafted Dockerfile

FROM nginx:alpine
COPY index.html /usr/share/nginx/html/

Feeling confident, inside Cloud Shell, I ran: docker build -t lyzolaregistry.azurecr.io/lyzola:v1 .

docker build -t lyzolaregistry.azurecr.io/lyzola:v1 .

…and Azure hit me with this:

Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?

Ah! My “boss” vibe dropped instantly 😂. Turns out Cloud Shell doesn’t run Docker locally. Lesson learned → use ACR Tasks instead of trying to build directly inside Cloud Shell.

---

🔑 Step 2: Azure Container Registry (ACR) Shuffle

I paused, looked at my files, and thought: “I’m already in the cloud… maybe there’s a better way?”

Enter Azure Container Registry Tasks and the lifesaver command: az acr create \ --resource-group lyzola-rg \ --name lyzolaregistry \ --sku Basic

But when deploying, I made a rookie mistake… I copy-pasted commands with angle brackets:

--registry-username <your-username>
--registry-password <your-password>

Azure was like:

 your-username: No such file or directory

😂 See me see wahala! 💡Pro tip: never leave <placeholders> in commands. I fixed it by fetching the real credentials

With the right username/password, my container was finally authorized to pull images.

✅ The magic here: my files were built in the cloud, no local Docker needed. Logs streamed in like a local build, and my image was safely tucked in ACR.

🚀 Step 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

💡 Pro tip: --dns-name-label gives your container a public URL, and adding randomness ($RANDOM) keeps it unique.

A quick follow-up command to get my URL:

az container show --name lyzola-container --resource-group myResourceGroup --query ipAddress.fqdn -o tsv

I copied the output URL, pasted it into a new tab, and just like that… my site was live! 🎉 All without ever needing Docker on my local machine or in the Cloud Shell

✅ IP worked.
✅FQDN worked

“So that’s how my fashion house finally got a home in the cloud. If you smiled, learned, or shouted ‘Yippee!!’ with me, then my work here is done. — This is cloudy, we stay stylish! 🌸

---

🧹 Step 4: 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

1. Cloud Shell ≠ Docker Host →It manages Azure resources, it doesn’t run Docker. Use ACR Tasks in such cases .

2. Docker build ≠ always possible in Cloud Shell

3. You can build anything in a Shell: Nano + terminal + knowledge = cloud deployment.

4. Embrace cloud-native workflows: az acr build handles daemon-less builds directly in ACR.

5. The Azure CLI is your friend: Build, push, and deploy—all in a few commands.

6. Angle brackets are evil (don’t forget to replace them).

7. Always specify a DNS label if you want that friendly URL.

8. Bundle your static assets — CSS/images matter.

9. Always clean up resources and files.

---

🎯 Wrapping It Up

In conclusion, my cloud deployment adventure was a journey filled with learning and growth. From the initial challenges of Docker daemon errors in Azure Cloud Shell to the successful deployment of my static fashion site using Azure Container Instances, each step taught me valuable lessons about cloud-native workflows and the power of Azure tools.

This whole journey was classic DevOps:

• Start with confidence 💪🏾

• Meet unexpected errors 😩

• Debug, retry, learn, and laugh 😂

• End with success 🎉

This adventure reminded me that sometimes the cloud has a better way, and it’s worth pausing to explore before banging your head on local limitations. This experience reinforced the importance of embracing cloud solutions, leveraging the Azure CLI, and maintaining a flexible mindset when faced with unexpected obstacles. Sharing this story highlights the dynamic nature of DevOps and the rewarding feeling of overcoming technical hurdles to achieve a successful deployment

That’s the fun of it — and why I love sharing the gist with you all. Because at the end of the day, it’s not just about containers and clouds; it’s about the stories behind them.

Have you ever hit the Docker daemon issue in Cloud Shell? How did you get around it? Share your stories below—I’d love to hear them! 👇

---

---