New Section: Dockerfile ENTRYPOINT and CMD

[ivorscott]

Fixes issue #90

Section: ENTRYPOINT and/vs CMD

• Lecture 1 basic info, no examples
• Lecture 2 Entrypoint for CLI with example
• Assignment 1 Entrypoint for curl cli
• Lecture 3 Entrypoint for pre-CMD scripts with example
• Lecture 4 Entrypoints in official images for script automation
• Assignment 2 Entrypoint for react app with env var for API_URL
• Quiz

[BretFisher]

Were you planning to remove all images? I still see the Excalidraw slides. Let's just remove Excalidraw images for now until I know what one's I'll need.

I like to teach ENTRYPOINT + CMD in two steps: 1st teach them that it just combines the two. 2nd, teach the "why" as two main use cases:

1. Use ENTRYPOINT to run CLI commands while specifying options at runtime. ()
2. Use ENTRYPOINT to run a script before it passes execution to CMD. (this has to be explained in detail on how exec "$@" works in bash and how that relates to ENTRYPOINT + CMD)

I generally like to show using CLI command examples (like curl) before I dig into entrypoint script examples (due to their complexity of passing execution).

Can we separate the lectures out to fit this format, and revise examples:

• Lecture 1: ENTRYPOINT's and how they relate to CMD (no exercise demos, just concepts)
• Lecture 2: Using ENTRYPOINT for CLI commands (use my bretfisher/httping image as Exercise)
• Assignment 1: create Dockerfile to build an image for CLI command of curl
• Lecture 3: Using ENTRYPOINT for running a script before starting a long-running program (use postgres image as Exercise, showing how Docker Hub can help us find the entrypoint script and how setting a username as env gets used in entrypoint script to create db user).
• Lecture 4 Using ENTRYPOINT automation providers. This extends on lecture 3 and shows now postgres, MySQL, nginx, and others provide a fancy ENTRYPOINT that lets you drop files in a specific location to have them execuited, like sql imports, shell scripts, etc.
• Assignment 2: create Dockerfile and entrypoint script to run a react app that calls a API, but we change API URL before nginx starts. We'll need to create that maybe (I have some existing research we can use)
• Quiz

Existing compose lecture: This above section is planning to be added before they learn about Docker Compose, so maybe move that markdown to a new issue in backlog to add entrypoint/command to the Docker Compose section at a later date.

[BretFisher]

In markdown, a LF/CR in a sentence or paragraph doesn't affect HTML formatting, so it's best to leave at 150 (meant for log lines, code, or cli commands) and just LF/CR at end of sentences.

[mandyhades]

good job

[BretFisher]

Each correct answer also has to indicate why it's correct. I recommend changing:

- __Answser: A__

to

__A) Correct. The two together create a flexible way to control what the container executes on start.__

Then change other Q&A Answers to match.

[BretFisher]

a joke.

[BretFisher]

This question isn't covered in the lessons. We should only test what we've taught.

[BretFisher]

@ivorscott I updated the OP to reflect the new flow and lecture subjects

[BretFisher]

Per the prior PR review, I think the examples and assignments need some reorganizing:

• examples should be realistic and useful. Showing how to run nginx -h to show off a CLI example isn't a real-world use case... or at least not one I've seen needed in the wild. using something like bretfisher/httping could be a useful replacement to the nginx -h one. The curl assignment is a perfect use case.
• remember that if we create scripts or code, we don't want them getting distracted in what the code does itself, if it's just used to show off a Docker feature. With rick.sh, I thought we were showing off entrypoint + cmd for running startup scripts, or passing values to a script, but it actually focuses on trap and signals, and that's too much to cover in a single lecture I think. I'd rather have rick.sh just show off sending a optional value to a script, and leave signals (and how shell/exec affects them) for a lecture later (really, it could be a whole section where we show off the signal problem, talk about pid1 wrappers like tini, etc. (which we do some of in Docker for Node.js)

[BretFisher]

I'd rather us add value here rather than just repeating the docs. Maybe we make it recommendations rather than rules. Let's mix them up with added info like this (replaces rules and gotcha):

Recommendations for using CMD and ENTRYPOINT.

1. Dockerfile should specify at least one of the CMD or ENTRYPOINT commands.
2. Like other run-time metadata, CMD and ENTRYPOINT` are not relevant until a container is started.
3. Docker only stores the last CMD and ENTRYPOINT in the Dockerfile. It'll also look at FROM images if they are missing in the current Dockerfile.
4. Default for most custom Dockerfiles to just setting CMD. You typically only add ENTRYPOINT if you want a startup script or to create a CLI command. Said another way, don't use ENTRYPOINT by itself. It'll work, but the convention of simple Dockerfiles (e.g. running a Python script or Node.js server) is to put it all in CMD.
5. If ENTRYPOINT uses the shell format, CMD is ignored. Default to using exec format in both (the JSON syntax). Only use shell format when you know why you're doing it that way (e.g. you need shell variables in the command).

[BretFisher]

By convention, don't use 1) for numbered lists in Markdown. It doesn't always work. Use 1. for all items in the list and the rendered output will order them properly. Always using 1. for all ordered list items is a standard in my courses, and allows for easier re-ordering or inserting an item in an existing list.

[BretFisher]

I like the rickroll, but I feel like we're going too far down the signals path, which we have yet to explain them in the course. The student won't fully understand linux signals yet. It's actually worth a lecture on them in in an advanced containers section, but not here. I'd rather the example show how a script can run via entrypoint and then pass execution to the CMD. Let's talk about it in relation to the other examples I mentioned in a previous PR Review.