十六、停止與重新啟動

停止：

docker stop fastapi-demo

啟動：

docker start fastapi-demo

重新啟動：

docker restart fastapi-demo

刪除：

docker rm fastapi-demo

如果 Container 正在執行：

docker rm -f fastapi-demo

十七、Container 刪掉後 Image 還在

這也是一個很重要的觀念。

例如：

Image

fastapi-deployment-lab:v1

根據它建立：

Container A

刪掉 Container A：

Container A X

Image 還是存在。

因此可以：

docker run \
    -d \
    -p 8000:8000 \
    fastapi-deployment-lab:v1

重新建立另一個完全相同的 Container。

也就是：

Image
   │
   ├── Container 1
   ├── Container 2
   └── Container 3

這就是 Image 作為：

Application Template

的重要意義。

十八、修改程式後會發生什麼？

假設：

@app.get("/")
async def root():
    return {
        "message": "Hello Docker"
    }

本機 Source Code 已經改了。

但是正在執行的 Container 不會自己改變。

因為它是從：

fastapi-deployment-lab:v1

建立出來的。

你要重新：

docker build \
    -t fastapi-deployment-lab:v2 .

產生：

v2

然後：

docker stop fastapi-demo
docker rm fastapi-demo

再：

docker run \
    -d \
    --name fastapi-demo \
    -p 8000:8000 \
    fastapi-deployment-lab:v2

這就是 Docker 部署的一個重要思維：

不要進去修改正在執行的 Container，而是 Build 新 Image，再用新 Container 替換舊 Container。

十九、這跟 systemd 部署到底差在哪？

現在可以直接比較。

傳統 systemd：

Server
│
├── Python
├── virtualenv
├── pip packages
├── Application Code
├── systemd
└── FastAPI Process

Docker：

Server
│
├── Docker
│
└── Container
    ├── Python
    ├── pip packages
    ├── Application Code
    └── Uvicorn

最大的差別在：

Application Environment

從：

Host 管理

變成：

Image 管理

二十、systemd 部署時，Server 要準備什麼？

systemd 方式：

Server A

需要：

Python

virtualenv

pip dependencies

source code

systemd unit

部署可能：

ssh server

cd /var/www/app

git pull

source .venv/bin/activate

pip install -r requirements.txt

sudo systemctl restart fastapi

也就是：

Server 本身
必須理解 Application 的執行環境