📮 धडा 11 — CI आणि containers मधल्या scripts: मेलरूम

📍 तुम्ही इथे आहात: 12 पैकी धडा 11 · पुढे: lesson-12-debugging-testing

📦 या ब्रँचमध्ये काय आहे

धडे 01–11. त्याच scripts, CI runner ने आणि container च्या आत चालवलेल्या — काय बदलते, आणि प्रत्येक entrypoint ला लागणाऱ्या तीन ओळी.

tests/run_tests.sh — CI step जे चालवते ते
bin/backup.sh — terminal, prompt, रंग यांच्याशिवाय चालणारी script

🧒 5 वर्षांच्या मुलाला समजावल्यासारखे

मेलरूम (CI) मध्ये आणि shipping container (Docker) च्या आत केअरटेकरचे ऑफिस नसते: screen नाही, keyboard नाही, प्रश्नाचे उत्तर द्यायला कोणी नाही. script ला जे environment दिले जाते त्यातूनच तिला सगळे कळायला हवे, तिने काय केले ते log मध्ये सांगायला हवे, आणि एक exit code परत द्यायला हवा. container च्या आत script ही बऱ्याचदा इमारतीतली अगदी पहिली व्यक्ती असते — PID 1 — म्हणून तिची शेवटची कृती म्हणजे बाजूला होऊन खऱ्या program ला badge घेऊ देणे: exec "$@".

🗺️ आकृती

flowchart LR
  G["📮 GitHub Actions<br/>run: bash tests/run_tests.sh"] --> X["exit 0 → green tick<br/>exit 1 → red cross"]
  D["🐳 docker run img"] --> E["entrypoint.sh<br/>set -euo pipefail · read $ENV · exec \"$@\""] --> A["the app as PID 1"]

❓ काय

Shebang: #!/usr/bin/env bash PATH वर bash शोधतो; #!/bin/sh म्हणजे POSIX sh — alpine आणि busybox मध्ये bash नसतो. Bashisms: [[ ]], arrays, ${x//a/b}, local, pipefail.
CI: non-interactive (TERM dumb असू शकतो; prompts नाहीत; < /dev/null), नवा checkout, secrets env vars म्हणून, exit code हिरवी खूण ठरवतो.
Containers: ENTRYPOINT ["bin/entrypoint.sh"], CMD ["app"]; script तयारी करते (env, config, migrations) मग exec "$@"; TERM app पर्यंत पोहोचावा म्हणून tini किंवा exec.
Secrets: script मध्ये किंवा image मध्ये कधीच नाहीत; environment मधून किंवा store मधून; त्या छापू शकणाऱ्या कोणत्याही गोष्टीभोवती set +x.
Locale आणि tools वेगळे असतात: sed -i, date, readlink -f हे macOS आणि Linux मध्ये वेगळे वागतात — तुम्ही ship करता त्याच container मध्ये test करा.

🤔 का

"माझ्या machine वर चालते" याचे कारण जवळजवळ नेहमी environment असते: PATH, HOME, shell, locale, तुमच्या laptop वर असलेला पण image मध्ये नसलेला एखादा tool. सुरुवातीपासूनच मेलरूमसाठी लिहिलेल्या scripts ना हा त्रास कधीच होत नाही.

🔧 कसे (या repo मध्ये)

इथल्या प्रत्येक script मध्ये #!/usr/bin/env bash, strict mode आहे, prompts नाहीत, आणि ती आपले inputs flags मधून किंवा SCHOOL_REGISTER मधून घेते. CI/CD शाळा या repo च्या प्रत्येक push वर tests/run_tests.sh चालवते.

🧪 करून पाहा

bash -n bin/*.sh && echo "syntax ok"                              # what a CI lint step does first
env -i PATH=/usr/bin:/bin HOME=/nonexistent bash tests/run_tests.sh | tail -1   # a bare environment, like cron or CI
docker run --rm -v "$PWD:/s" -w /s bash:5 bash tests/run_tests.sh | tail -1    # (if Docker) inside a container
docker run --rm -v "$PWD:/s" -w /s alpine sh -c 'sh bin/school.sh list'        # alpine has no bash: watch it fail on [[ ]]
cat > /tmp/entrypoint.sh <<'EOF'
#!/usr/bin/env bash
set -euo pipefail
echo "preparing with REGISTER=${SCHOOL_REGISTER:-default}" >&2
exec "$@"
EOF
chmod +x /tmp/entrypoint.sh; SCHOOL_REGISTER=x /tmp/entrypoint.sh echo "now I am the app"

✅ तपासा — तुम्हाला काय दिसायला हवे

syntax ok; मोकळ्या environment मध्ये आणि bash container मध्ये 14 passed, 0 failed; alpine चा run पहिल्याच bashism वर fail होतो; entrypoint आपली तयारी stderr वर log करते आणि echo बदललेला process म्हणून चालतो.

🏁 तुम्ही आत्ताच काय सिद्ध केले

तुमच्या scripts मोकळ्या environment मध्ये आणि container मध्ये टिकतात, आणि PID 1 खऱ्या program कडे सोपवणारी entrypoint तुम्ही लिहू शकता.

⚠️ नेहमीच्या चुका

[[ ]] ने भरलेल्या script वर #!/bin/sh — Ubuntu वर चालते (dash तुम्हाला वाटते त्यापेक्षा कमी सहन करतो), alpine वर मरते.
set -x चालू असताना secret छापणे.
exec ./app ऐवजी ./app ने संपणारी entrypoint — app ला TERM कधीच मिळत नाही.

🏭 प्रत्यक्ष वापरात हे का महत्त्वाचे: प्रत्येक Dockerfile चा ENTRYPOINT, प्रत्येक CI run: block, प्रत्येक kubectl exec … sh म्हणजे हाच धडा. Docker आणि CI/CD शाळा म्हणजे जिथे या scripts राहतात.

⏭️ पुढे

धडा 12 — debugging आणि testing: script काय करते ते पाहा, आणि bash मध्ये लिहिलेल्या test runner ने ते सिद्ध करा.

📮 Lesson 11 — Scripts in CI & containers: the mailroom

📍 You are here: Lesson 11 of 12 · Next: lesson-12-debugging-testing

📦 What's in this branch

Lessons 01–11. The same scripts, run by a CI runner and inside a container — what changes, and the three lines every entrypoint needs.

tests/run_tests.sh — what a CI step runs
bin/backup.sh — a script that works with no terminal, no prompt, no colour

🧒 Explain like I'm 5

In the mailroom (CI) and inside a shipping container (Docker) there is no caretaker's office: no screen, no keyboard, nobody to answer a question. The script must know everything from the environment it is handed, say what it did in the log, and hand back one exit code. Inside the container the script is often the very first person in the building — PID 1 — so its last act should be to step aside and let the real program take the badge: exec "$@".

🗺️ Diagram

flowchart LR
  G["📮 GitHub Actions<br/>run: bash tests/run_tests.sh"] --> X["exit 0 → green tick<br/>exit 1 → red cross"]
  D["🐳 docker run img"] --> E["entrypoint.sh<br/>set -euo pipefail · read $ENV · exec \"$@\""] --> A["the app as PID 1"]

❓ What

Shebang: #!/usr/bin/env bash finds bash on the PATH; #!/bin/sh is POSIX sh — alpine and busybox have no bash. Bashisms: [[ ]], arrays, ${x//a/b}, local, pipefail.
CI: non-interactive (TERM may be dumb; no prompts; < /dev/null), a fresh checkout, secrets as env vars, the exit code decides the tick.
Containers: ENTRYPOINT ["bin/entrypoint.sh"], CMD ["app"]; the script prepares (env, config, migrations) then exec "$@"; tini or exec so TERM reaches the app.
Secrets: never in the script or the image; from the environment or a store; set +x around anything that would print them.
Locale and tools differ: sed -i, date, readlink -f vary between macOS and Linux — test in the container you ship.

🤔 Why

"Works on my machine" is almost always the environment: PATH, HOME, the shell, the locale, a tool that exists on your laptop and not in the image. Scripts written for the mailroom from the start never hit it.

🔧 How (in this repo)

Every script here has #!/usr/bin/env bash, strict mode, no prompts, and takes its inputs from flags or SCHOOL_REGISTER. The CI/CD school runs tests/run_tests.sh on every push of this repo.

🧪 Try it

bash -n bin/*.sh && echo "syntax ok"                              # what a CI lint step does first
env -i PATH=/usr/bin:/bin HOME=/nonexistent bash tests/run_tests.sh | tail -1   # a bare environment, like cron or CI
docker run --rm -v "$PWD:/s" -w /s bash:5 bash tests/run_tests.sh | tail -1    # (if Docker) inside a container
docker run --rm -v "$PWD:/s" -w /s alpine sh -c 'sh bin/school.sh list'        # alpine has no bash: watch it fail on [[ ]]
cat > /tmp/entrypoint.sh <<'EOF'
#!/usr/bin/env bash
set -euo pipefail
echo "preparing with REGISTER=${SCHOOL_REGISTER:-default}" >&2
exec "$@"
EOF
chmod +x /tmp/entrypoint.sh; SCHOOL_REGISTER=x /tmp/entrypoint.sh echo "now I am the app"

✅ Verify — what you should see

syntax ok; 14 passed, 0 failed in the bare environment and in the bash container; the alpine run fails at the first bashism; the entrypoint logs its preparation to stderr and the echo runs as the replaced process.

🏁 What you just proved

Your scripts survive a bare environment and a container, and you can write the entrypoint that hands PID 1 to the real program.

⚠️ Common mistakes

#!/bin/sh on a script full of [[ ]] — works on Ubuntu (dash tolerates less than you think), dies on alpine.
Printing a secret with set -x on.
An entrypoint that ends with ./app instead of exec ./app — the app never receives TERM.

🏭 Why this matters in production: every Dockerfile's ENTRYPOINT, every CI run: block, every kubectl exec … sh is this lesson. The Docker and CI/CD schools are where these scripts live.

⏭️ Next

Lesson 12 — debugging & testing: see what a script does, and prove it with a test runner written in bash.

← Previousscheduling Next →debugging testing

This page is the lesson's README from the lesson-11-ci-and-containers branch, shown here so the whole School stays on one site. Code files open on GitHub at the same branch.