---
title: "Maintainable Python Deployments at Scale: Decoupling Build from Runtime - Justin Lee"
tags: PyConTW2025, 2025-organize, 2025-共筆
---

# Maintainable Python Deployments at Scale: Decoupling Build from Runtime - Justin Lee

{%hackmd L_RLmFdeSD--CldirtUhCw %}

<iframe src=https://app.sli.do/event/2sn9LKJMTeDvyXjCAwcjoG height=450 width=100%></iframe>

:::success
本演講提供 AI 翻譯字幕及摘要，請點選這裡前往 >> [PyCon Taiwan AI Notebook](https://pycontw.connyaku.app/?room=9cBvJQ3VFECzGr802e1X)
AI translation subtitles and summaries are available for this talk. Click here to access >> [PyCon Taiwan AI Notebook](https://pycontw.connyaku.app/?room=9cBvJQ3VFECzGr802e1X)
:::

> Collaborative writing start from below
> 從這裡開始共筆

## Context
- Make python more reproducibale and easier to deployment with python tools.
- Not about how to get rid of docker
- Not everything needs to live in your Docker image. (Decoupling)
- Sys deps are set in the docker image
- Python deps and custom code exists outside of the image
- Dockerfiles in a organization starts to grow with inheritances, and eventually becomes a black box.

### The hidden cost
- Most time we use docker, it only requires to work on one single Dockerfile file
- The application is bundled as an immutable docker image. It gives confidence that this might works in different environment.
- However, this may not be good at scaling.
- More python docker apps, more docker images. More docker images on top of it. There're tons of docker images to maintain. What if we want to upgrade python version?
- Rebuild for any change
- Docker Image Sprawl
- Operational Overhead
- Building a docker image for this causes maintaining and scalability challenges.

### Layers

Bundle these layers coupled the system with applications, which makes the challenge.

- System Dependency
- Python Dependency
- Python Application

### Attempts to Use `entrypoint.sh` to install python dependencies and the application.
- Base Docker image with system dependencies + multiple `application_#.zip`
- Solves all issues above
- Tradeoffs
- increaed startup latency. Python dep install can be very slow.
- complexity of managing python applications (The zip files)

# entrypoint.sh
#!/bin/bash

curl -o $PROJ_FILE.zip
unzip $PROJ_FILE.zip

pip install -r requirements.txt

python app.py

### Proposal

#### Strategy 1 - Cache virtual environments

### Pack

$ python -m venv .venv
$ source .venv/bin/activate
(venv) $ pip install -r requirements.txt
$ zip -r my_venv.zip .venv

### Unpack

unzip my_env.zip
source .venv/bin/activate
pip list

- venv is just a directory. It's cacheable
- Don't need to wait for python deps to be installed.
- ==Limitation==: the environment needs to be the same

# md5(requirements.txt)
if "<md5_hash>" in cache:  # find cache in database
    # download + unzip
else:
    # create venv and install packages
    # zip and upload to cache under md5_hash

#### Strategy 2 - Portable Python with PEP 441

- PEP441
- Introduces a way to package entire python application as a single .pyz file
- Shiv archieve (Open Source tool created by linkedin)
- Base docker image with system deps + application_#.pyz
- More enterprise ready.

### Conclusion
- Not expected that this approach works for everyone. Don't be afraid to question it.

---

Below is the part that speaker updated the talk/tutorial after speech
講者於演講後有更新或勘誤投影片的部份