Docker deployment for Deno - Step-by-Step Execution

Concept Flow - Docker deployment for Deno

Write Deno app code

↓

Create Dockerfile

↓

Build Docker image

↓

Run Docker container

↓

App runs inside container

↓

Access app via exposed port

This flow shows how you write your Deno app, create a Dockerfile to containerize it, build the image, run the container, and then access the running app.

Execution Sample

Deno

import { serve } from "https://deno.land/std@0.201.0/http/server.ts";

serve(() => new Response("Hello from Deno in Docker!"), { port: 8000 });

A simple Deno HTTP server that responds with a greeting message on port 8000.

Execution Table

Step	Action	Command/Code	Result/Output
1	Write Deno app code	Create server.ts with serve() code	Deno app ready to run
2	Create Dockerfile	Write Dockerfile with Deno base image and copy server.ts	Dockerfile ready
3	Build Docker image	docker build -t deno-app .	Docker image 'deno-app' created
4	Run Docker container	docker run -p 8000:8000 deno-app	Container runs, app listens on port 8000
5	Access app	Open browser at http://localhost:8000	Page shows 'Hello from Deno in Docker!'
6	Stop container	Ctrl+C or docker stop	Container stops, app no longer accessible

💡 Execution stops after container is stopped or user closes app.

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	After Step 5	Final
Deno app code	None	server.ts created	Unchanged	Unchanged	Unchanged	Unchanged	Unchanged
Dockerfile	None	None	Dockerfile created	Unchanged	Unchanged	Unchanged	Unchanged
Docker image	None	None	None	Image built	Unchanged	Unchanged	Unchanged
Docker container	None	None	None	None	Container running	Unchanged	Stopped

Key Moments - 3 Insights

Why do we need to expose port 8000 in the Docker run command?

Exposing port 8000 with '-p 8000:8000' maps the container's port to the host, allowing you to access the app from your browser. Without this, the app runs inside the container but is not reachable externally (see execution_table step 4).

What happens if the Dockerfile does not copy the server.ts file?

If server.ts is not copied into the image, the container will fail to run the app because the code is missing. This is shown in execution_table step 2 where Dockerfile must copy the app code.

Why do we use a Deno base image in the Dockerfile?

The Deno base image includes the Deno runtime needed to run the app inside the container. Without it, the container would not know how to execute the Deno code (refer to execution_table step 2).

Visual Quiz - 3 Questions

Look at the execution_table, what command builds the Docker image?

A docker run -p 8000:8000 deno-app

B docker build -t deno-app .

C docker stop

D serve(() => new Response(...))

💡 Hint

Check the 'Build Docker image' step in the execution_table.

At which step does the app become accessible from the browser?

A Step 3

B Step 4

C Step 5

D Step 6

💡 Hint

Look for the step where the browser opens http://localhost:8000 in the execution_table.

If you forget to expose port 8000 in 'docker run', what happens?

A The app runs but is not reachable from outside the container.

B The container will not start.

C The app will crash immediately.

D The Docker image will not build.

💡 Hint

Refer to the key moment about port exposure and execution_table step 4.

Concept Snapshot

Docker deployment for Deno:
1. Write your Deno app (e.g., server.ts).
2. Create a Dockerfile using a Deno base image.
3. Copy app code into image.
4. Build image with 'docker build'.
5. Run container exposing needed ports.
6. Access app via localhost and port.

Full Transcript

This visual execution shows how to deploy a Deno app using Docker. First, you write a simple Deno server script. Then, you create a Dockerfile that uses a Deno base image and copies your app code inside. Next, you build the Docker image with 'docker build'. After that, you run the container with port 8000 exposed so you can access the app from your browser. Finally, you open the browser at localhost:8000 to see the app running inside the container. Stopping the container ends the app. Key points include exposing ports to access the app and ensuring the app code is copied into the image.

Practice

1. What is the main purpose of using Docker for deploying a Deno application?

easy

A. To replace the Deno runtime

B. To write Deno code faster

C. To package the app so it runs the same on any machine

D. To debug Deno code inside the browser

Solution

1. Step 1: Understand Docker's role

   Docker packages apps with all dependencies so they run consistently anywhere.

2. Step 2: Relate to Deno deployment

   Using Docker for Deno ensures the app runs the same on any machine without setup issues.

3. Final Answer:

   To package the app so it runs the same on any machine -> Option C

4. Quick Check:

   Docker packages apps = To package the app so it runs the same on any machine [OK]

Hint: Docker ensures consistent app environment everywhere [OK]

Common Mistakes:

• Thinking Docker speeds up coding
• Confusing Docker with Deno runtime
• Assuming Docker is for debugging only

2. Which Dockerfile instruction correctly sets the command to run a Deno script named app.ts with all permissions?

easy

A. CMD ["deno", "run", "--allow-all", "app.ts"]

B. RUN deno run --allow-all app.ts

C. ENTRYPOINT deno app.ts

D. CMD deno start app.ts

Solution

1. Step 1: Identify correct Dockerfile command syntax

   CMD with JSON array syntax is preferred for commands with arguments.

2. Step 2: Match Deno run command with permissions

   "deno run --allow-all app.ts" runs the script with all permissions; CMD array syntax is correct.

3. Final Answer:

   CMD ["deno", "run", "--allow-all", "app.ts"] -> Option A

4. Quick Check:

   Use CMD with JSON array for run command [OK]

Hint: Use CMD with JSON array for Deno run commands [OK]

Common Mistakes:

• Using RUN instead of CMD for runtime command
• Omitting --allow-all permission flag
• Using ENTRYPOINT without arguments array

3. Given this Dockerfile snippet:

FROM denoland/deno:latest
WORKDIR /app
COPY . .
RUN deno cache app.ts
CMD ["deno", "run", "--allow-net", "app.ts"]

What happens when you build and run this container?

medium

A. The app runs with network access allowed

B. The app runs but without network access

C. The container build fails due to missing permissions

D. The app runs but caching is skipped

Solution

1. Step 1: Analyze Dockerfile commands

   The Dockerfile caches dependencies with "deno cache app.ts" and runs the app with "--allow-net" permission.

2. Step 2: Understand runtime behavior

   CMD runs the app allowing network access, so the app can use network features.

3. Final Answer:

   The app runs with network access allowed -> Option A

4. Quick Check:

   --allow-net enables network access = The app runs with network access allowed [OK]

Hint: Check permission flags in CMD to know app access [OK]

Common Mistakes:

• Confusing cache step with runtime permissions
• Assuming build fails without --allow-all
• Ignoring the effect of --allow-net flag

4. You wrote this Dockerfile:

FROM denoland/deno:latest
WORKDIR /app
COPY . .
CMD ["deno", "run", "app.ts"]

But when running the container, the app crashes with permission errors. What is the fix?

medium

A. Remove COPY command

B. Change WORKDIR to /usr/src/app

C. Use RUN instead of CMD for deno run

D. Add permission flags like --allow-net to the CMD

Solution

1. Step 1: Identify cause of permission errors

   Deno requires explicit permission flags to access resources like network or file system.

2. Step 2: Fix Dockerfile CMD to include permissions

   Add flags like --allow-net or --allow-read to CMD so app has needed permissions at runtime.

3. Final Answer:

   Add permission flags like --allow-net to the CMD -> Option D

4. Quick Check:

   Permission errors need flags in CMD [OK]

Hint: Add needed --allow-* flags to CMD to fix permission errors [OK]

Common Mistakes:

• Changing WORKDIR without cause
• Removing COPY which copies app files
• Using RUN instead of CMD for runtime command

5. You want to optimize your Deno Docker image by caching dependencies to speed up builds. Which Dockerfile sequence achieves this best?

hard

A. COPY . .
RUN deno cache app.ts
CMD ["deno", "run", "--allow-all", "app.ts"]

B. COPY deps.ts ./
RUN deno cache deps.ts
COPY . .
CMD ["deno", "run", "--allow-all", "app.ts"]

C. RUN deno cache app.ts
COPY . .
CMD ["deno", "run", "app.ts"]

D. COPY app.ts ./
CMD ["deno", "run", "app.ts"]

Solution

1. Step 1: Understand Docker layer caching

   Docker caches layers; caching dependencies separately avoids re-downloading on code changes.

2. Step 2: Analyze COPY deps.ts ./ RUN deno cache deps.ts COPY . . CMD ["deno", "run", "--allow-all", "app.ts"]

   Copying only deps.ts and caching it first means dependencies are cached unless deps.ts changes, then copying rest avoids rebuilding cache.

3. Step 3: Compare other options

   Options A and C copy all files before caching, so cache invalidates on any file change; D lacks caching step.

4. Final Answer:

   COPY deps.ts ./ RUN deno cache deps.ts COPY . . CMD ["deno", "run", "--allow-all", "app.ts"] -> Option B

5. Quick Check:

   Cache deps separately for faster rebuilds [OK]

Hint: Cache dependencies before copying app code to speed builds [OK]

Common Mistakes:

• Copying all files before caching dependencies
• Skipping deno cache step
• Not using permission flags in CMD