Podman vs Docker trên VPS: khác nhau thực tế gì?

Điểm khác biệt thực tế giữa Podman và Docker

Podman và Docker chạy cùng các image OCI (open container initiative) trên một VPS, nên lựa chọn không phụ thuộc vào việc phần mềm nào có thể chạy. Khác biệt nằm ở mô hình tiến trình. Docker chạy một daemon với quyền root quản lý mọi container, còn lệnh docker là một client nhỏ gửi yêu cầu để daemon đó thực hiện công việc. Podman không có daemon: podman run khởi động container dưới dạng tiến trình con của tiến trình đã gọi nó, bằng user không có quyền đặc biệt của bạn.

Mọi khác biệt khác đều bắt nguồn từ điểm này. systemd chịu trách nhiệm tự động khởi động thay cho daemon. Quyền sở hữu volume đi qua user namespace, nên owner bạn thấy bằng ls -l trên host không phải là owner mà container thấy. Các port dưới 1024 sẽ không bind được cho đến khi bạn thay đổi thiết lập kernel. CLI docker (command line interface) vẫn hoạt động thông qua một wrapper, cho đến khi có thành phần cần Docker socket.

Không có daemon: thực tế điều gì chạy khi bạn khởi động một container

Trên một Docker host, pstree -a hiển thị dockerd dưới dạng root, containerd bên cạnh nó và một containerd-shim-runc-v2 cho mỗi container đang chạy. Ứng dụng của bạn là tiến trình con của shim đó, còn shim là tiến trình con của PID 1. Không có thành phần nào kết nối container với shell đã khởi động nó. Dừng daemon sẽ làm mất control plane của mọi container trên máy. Khi tắt thiết lập mặc định live-restore, systemctl restart docker cũng sẽ khởi động lại các container của bạn.

Podman không có tiến trình tương đương. Khi khởi động một container, bạn sẽ có một tiến trình conmon (container monitor) giữ tiến trình chính của container. Tiến trình này thuộc về user đã chạy command.

podman run -d --name web -p 8080:80 docker.io/library/caddy:2
ps -o user,pid,ppid,args -C conmon
curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8080

ps phải liệt kê conmon đang chạy bằng login user của bạn, không phải root. curl phải in ra 200. Vì không có service trung tâm sở hữu container, sudo apt upgrade podman không dừng những container đang chạy. Nếu monitor của một container bị crash, các container khác cũng không bị ảnh hưởng.

Việc không có daemon cũng có một cái giá. Không có thành phần nào tự khởi động các container sau khi reboot. --restart=always của Docker là cam kết mà daemon thực hiện khi boot. Podman thay thế cơ chế này bằng systemd. Đây là mục đích của phần quadlet bên dưới.

Socket là nửa còn lại của vấn đề. /var/run/docker.sock là endpoint API (application programming interface) thuộc sở hữu của root. Bất kỳ process nào có thể ghi vào đó đều có thể khởi động một container có quyền cao và mount filesystem của host. Thêm một user vào group docker sẽ cấp cho user đó quyền root theo một cách vòng hơn. Bạn nên đọc phần này cùng với chỉ cấp cho mỗi service account quyền truy cập cần thiết. Podman không expose socket trừ khi bạn yêu cầu. Socket được tạo ra sẽ thuộc về một user duy nhất tại /run/user/<uid>/podman/podman.sock.

Cài Podman trên Ubuntu 24.04 và xác nhận rootless hoạt động đúng

sudo apt update
sudo apt install -y podman uidmap
podman --version
podman info | grep -i rootless

Gói uidmap cung cấp newuidmap và newgidmap. Đây là các helper setuid cho phép user thông thường sử dụng một dải subordinate ID. Nếu thiếu chúng, rootless container sẽ không khởi động. podman info phải in ra rootless: true.

Ubuntu 24.04 cung cấp Podman 4.9, còn Debian 13 cung cấp Podman 5.x, theo kiểm tra vào tháng 8 năm 2026. Khác biệt này quan trọng vì file quadlet cần phiên bản 4.4 trở lên, còn file quadlet .pod cần phiên bản 5.0. Chạy podman --version trước khi sao chép ví dụ từ tài liệu upstream.

Mỗi user rootless cần một dải subordinate ID:

grep "$USER" /etc/subuid /etc/subgid

User được tạo bằng adduser trên Ubuntu sẽ tự động có dải ID. User được tạo bằng useradd -M hoặc bằng một công cụ cấu hình thường không có dải này, và lỗi sẽ nêu rõ nguyên nhân:

Error: cannot find UID/GID for user deploy: no subuid ranges found for user "deploy" in /etc/subuid - check rootless mode in man pages.

Gán một dải ID, sau đó reset storage của user đó để sử dụng mapping mới:

sudo usermod --add-subuids 100000-165535 --add-subgids 100000-165535 deploy
podman system migrate

Một bất ngờ khác trong lần chạy đầu tiên: Podman không mặc định dùng Docker Hub. Short image name được resolve dựa trên unqualified-search-registries trong /etc/containers/registries.conf. Khi chạy trong script không có terminal được gắn vào, thao tác pull sẽ fail với short-name resolution enforced but cannot prompt without a TTY. Luôn ghi đầy đủ image name. Dùng docker.io/library/nginx:1.27 thay cho nginx.

Rootless container thực sự mang lại gì trên một server thuê

Rootless container chạy bên trong user namespace, một tính năng của kernel cho phép process có một ánh xạ user ID riêng. Bên trong namespace, superuser của container là UID (user ID) 0. Bên ngoài namespace, trên VPS của bạn, process đó chỉ là user đăng nhập thông thường của bạn. Root trong container không phải root trên host.

Đó là phạm vi lợi ích thực tế. Một image bắt buộc phải chạy dưới quyền root, một web application có lỗi remote code execution, hoặc một cơ chế escape cần UID 0 ở bên ngoài: tất cả các trường hợp đó chỉ có quyền của user không có đặc quyền, thay vì quyền trên cả máy. Rootless không bảo vệ bạn khỏi bug của kernel. Nó cũng không bảo vệ các file của chính bạn, vì process sau khi escape vẫn chạy dưới user của bạn và có thể đọc mọi thứ mà bạn đọc được. Việc unit được cô lập quan trọng ít nhất ngang với việc ánh xạ UID. Điều này dễ thấy hơn ở FreeBSD jail, nơi bọc toàn bộ userland mà bạn quản trị như một máy nhỏ thay vì một image nhiều lớp được pull từ registry.

Docker cũng có thể chạy rootless. dockerd-rootless-setuptool.sh install thiết lập một daemon riêng cho từng user và hoạt động tốt. Điểm khác biệt nằm ở hướng mặc định. Với Podman, rootless là mặc định mà không cần yêu cầu thêm. Vì vậy, lỗi đầu tiên bạn gặp sẽ là container không thể bind vào port 80, thay vì một service âm thầm chạy dưới quyền root trong 2 năm.

Vì sao các file trong volume của tôi thuộc về UID 100999?

Nguyên nhân là cùng một user namespace đó. UID 0 trong container được ánh xạ tới UID của bạn trên host. UID 1 trong container được ánh xạ tới ID đầu tiên trong dải subuid của bạn, rồi tăng dần từ đó. Với dải bắt đầu từ 100000, UID 1000 trong container sẽ tương ứng với UID 100999 trên host.

mkdir -p "$PWD/data"
podman run --rm --user 1000 -v "$PWD/data:/data" docker.io/library/alpine:3 sh -c 'id -u; touch /data/f'
ls -ln "$PWD/data"

Container in ra 1000. Danh sách trên host hiển thị owner 100999, vì 100000 cộng 1000 trừ 1 bằng 100999. Không có gì bị hỏng, và lệnh chown thông thường cũng không sửa được việc này, vì user không có đặc quyền của bạn không thể thay đổi ownership của file bên ngoài namespace.

Có 4 cách xử lý:

• podman unshare chown 1000:1000 "$PWD/data" chạy chown bên trong cùng user namespace, nơi các con số có ý nghĩa đúng như container hiểu.
• -v "$PWD/data:/data:U" yêu cầu Podman tự sửa ownership của thư mục nguồn. Hãy dùng trên thư mục mới, không dùng trên dữ liệu bạn cần giữ nguyên.
• --userns=keep-id ánh xạ UID trên host của bạn tới cùng UID bên trong container, để các file mới tạo ra thuộc về bạn.
• Named volume như -v appdata:/data tránh được vấn đề này, vì Podman tạo volume bên trong storage của bạn với ownership đã đúng.

Nếu bạn từng gặp vấn đề này trong Docker thì đây là cùng một vấn đề, nhưng xảy ra thêm một lớp ánh xạ. Các biến PUID và PGID mà nhiều image cung cấp đặt UID mà process bên trong container sử dụng. Với rootless Podman, UID đó tiếp tục được ánh xạ thêm một lần nữa. PUID=1000 bên trong rootless container vẫn tạo ra các file trên host với owner là 100999. Hãy chọn các con số có tính đến lớp ánh xạ thứ hai này, hoặc chuyển dữ liệu vào named volume để không phải bận tâm nữa.

Có thêm 2 lưu ý về mount. Các flag :z và :Z thường thấy trong ví dụ dành cho Fedora và RHEL là tùy chọn relabel của SELinux; Ubuntu dùng AppArmor nên các flag này không có tác dụng ở đó. Rootless Podman cũng không thể mount một thư mục trên host mà user của bạn không có quyền đọc. Đây là hành vi bảo vệ đúng, không phải lỗi.

Vì sao rootless Podman từ chối publish port 80?

Vì bind port dưới 1024 cần một privilege mà user của bạn không có. Lỗi sẽ chỉ rõ cách khắc phục:

Error: rootlessport cannot expose privileged port 80, you can add 'net.ipv4.ip_unprivileged_port_start=80' to /etc/sysctl.conf (currently 1024), or choose a larger port number (>= 1024): listen tcp 0.0.0.0:80: bind: permission denied

Có 2 cách xử lý. Hạ threshold cho toàn bộ host:

echo 'net.ipv4.ip_unprivileged_port_start=80' | sudo tee /etc/sysctl.d/99-podman.conf
sudo sysctl --system
sysctl net.ipv4.ip_unprivileged_port_start

Lệnh cuối phải echo 80. Cần hiểu rõ setting này làm gì: mọi user trên máy đều có thể bind 80 và 443, không chỉ user đang chạy container. Với một VPS chỉ có 1 admin, đây là đánh đổi có thể chấp nhận. Với máy chủ có account của người khác, cách này không phù hợp. Cách còn lại là publish trên 8080 rồi đặt reverse proxy phía trước. Đây cũng là nơi bạn nên cấp và gia hạn certificate bằng certbot trên nginx.

Rootless publishing cũng thay đổi thông tin mà application nhận được. Podman 4.x mặc định dùng slirp4netns với rootlesskit port handler. Các connection được forward sẽ có source address đã bị rewrite, nên access log ghi mọi visitor là 10.0.2.100. Podman 5.0 đổi mặc định thành pasta và giữ lại địa chỉ client thực. Trên 4.x, --network slirp4netns:port_handler=slirp4netns khôi phục source address thực, nhưng throughput sẽ giảm phần nào.

Có một điểm đáng chú ý. Port được publish ở chế độ rootless là một listening socket thông thường do process không phải root sở hữu, nên các input rule của firewall vẫn áp dụng cho port này. Docker publish port bằng cách ghi các rule NAT (network address translation) cùng các rule accept forwarding riêng của nó. Đây chính là lý do port Docker đã publish không tuân theo rule ufw mà bạn tưởng đang chặn nó. Rootful Podman dùng cơ chế tương tự và cũng gặp bẫy này. Rootless thì không.

Các file Docker Compose của tôi còn hoạt động với Podman không?

Phần lớn là có, theo hai cách khác nhau. Cách đầu tiên là podman-compose, một implementation riêng đọc cùng file đó và điều khiển Podman CLI:

sudo apt install -y podman-compose
podman-compose up -d
podman ps

Cách thứ hai là dùng Docker Compose thật để kết nối đến Docker-compatible API của Podman qua socket riêng của từng user:

systemctl --user enable --now podman.socket
export DOCKER_HOST="unix:///run/user/$(id -u)/podman/podman.sock"
docker compose up -d
podman ps

docker compose ps và podman ps sẽ liệt kê cùng một nhóm container, vì chỉ có một nhóm container duy nhất. Name resolution cũng hoạt động: network backend mặc định của Podman là netavark, chạy aardvark-dns, nên các container trên user-defined network có thể tìm nhau bằng tên.

Các giới hạn vẫn tồn tại. Bất kỳ thành phần nào mount /var/run/docker.sock đều phải trỏ đến Podman socket hoặc bị loại bỏ. network_mode: host hoạt động khác trong user namespace. depends_on cùng với condition: service_healthy được hỗ trợ không đồng đều giữa các phiên bản podman-compose. restart: always không tự tồn tại sau khi reboot; phần tiếp theo sẽ khắc phục việc này. Compose vẫn là cách tốt để mô tả một stack gồm nhiều container trong một file duy nhất, còn với Podman, nó là một lớp chuyển đổi. Với stack dự định duy trì trong nhiều năm, hãy chuyển nó sang quadlet và duy trì một abstraction thay vì hai abstraction.

Pod: ý tưởng mà Docker không có câu trả lời

Pod là một nhóm container dùng chung một network namespace. Podman khởi động một container infra nhỏ để giữ namespace đó hoạt động, sau đó các thành viên có thể kết nối với nhau qua 127.0.0.1 mà không cần user-defined network và không cần service discovery.

podman pod create --name app -p 8080:80
podman run -d --pod app --name app-cache docker.io/library/redis:7
podman run -d --pod app --name app-web docker.io/library/nginx:1.27
podman pod ps
podman ps --pod

podman pod ps phải hiển thị pod Running cùng 3 container, bao gồm cả infra container. Container web giờ kết nối đến Redis tại 127.0.0.1:6379 thay vì tại app-cache:6379. Namespace dùng chung dẫn đến 2 quy tắc: publish port trên pod, không publish trên member; và không có 2 member nào được listen trên cùng một port.

Đây là model của Kubernetes, và Podman hỗ trợ sâu theo hướng này. podman kube generate app > app.yaml ghi một Kubernetes manifest từ trạng thái đang chạy (package cũ ghi là podman generate kube), còn podman kube play app.yaml tạo lại trạng thái đó trên host khác. Quadlet có một loại unit .kube để chạy file như vậy dưới dạng systemd service. Đây là cách nhóm service thực sự khác biệt, và là lý do thuyết phục nhất để chọn Podman nếu Kubernetes có thể nằm trong kế hoạch tương lai của bạn.

Tự động khởi động không cần daemon: các unit quadlet

Quadlet là một systemd generator. Nó chuyển một file ngắn mô tả container thành một systemd service thực sự khi boot. Các file được đặt trong ~/.config/containers/systemd/ đối với user rootless hoặc /etc/containers/systemd/ đối với root.

~/.config/containers/systemd/caddy.container:

[Unit]
Description=Caddy web server
After=network-online.target

[Container]
Image=docker.io/library/caddy:2
ContainerName=caddy
PublishPort=8080:80
Volume=caddy-data.volume:/data
Environment=TZ=UTC
AutoUpdate=registry

[Service]
Restart=always
MemoryMax=512M

[Install]
WantedBy=default.target

~/.config/containers/systemd/caddy-data.volume có thể gần như để trống, vì section header là thành phần tạo volume:

[Volume]

systemctl --user daemon-reload
systemctl --user start caddy
systemctl --user status caddy
journalctl --user -u caddy -n 50

Tên service được lấy từ tên file: caddy.container trở thành caddy.service. Không chạy systemctl --user enable caddy. Các unit được generate không thể enable, và systemd trả về Failed to enable unit: Unit /run/user/1000/systemd/generator/caddy.service is transient or generated. Section [Install] là phần khởi động container khi boot, còn daemon-reload là phần generate lại unit sau khi bạn chỉnh sửa file.

Bây giờ là setting khiến gần như mọi người đều gặp lỗi:

sudo loginctl enable-linger deploy
loginctl show-user deploy --property=Linger

Kết quả cần thấy là Linger=yes. Nếu không bật linger, systemd sẽ dọn toàn bộ user session khi kết nối SSH cuối cùng đóng. Khi đó mọi rootless container cũng dừng theo và không container nào tự khởi động lại khi boot. Container biến mất ngay khi bạn logout luôn có nguyên nhân này.

Vì container là process chính của một service unit thông thường, các cơ chế điều khiển của systemd áp dụng trực tiếp. MemoryMax= và CPUQuota= trong section [Service] hoạt động chính xác như với bất kỳ service nào khác mà bạn giới hạn bằng systemd. Cơ chế này cần cgroup v2 (control group version 2), được Ubuntu dùng mặc định từ 22.04. Xác nhận bằng podman info | grep -i cgroup.

Cơ chế update cũng có cách tương ứng. AutoUpdate=registry cùng với systemctl --user enable --now podman-auto-update.timer sẽ kiểm tra registry để tìm image mới hơn trên cùng tag, restart unit và rollback về image trước đó nếu container mới không khởi động được. Chạy podman auto-update --dry-run trước để xem các thay đổi dự kiến. Lệnh podman generate systemd cũ vẫn còn tồn tại nhưng đã deprecated, vì vậy hãy dùng quadlet cho mọi cấu hình mới.

Vị trí alias docker hoạt động và vị trí không hoạt động

sudo apt install -y podman-docker
sudo touch /etc/containers/nodocker
docker ps

podman-docker cài một wrapper /usr/bin/docker gọi Podman. Nếu không có file nodocker, mỗi lần gọi trước tiên sẽ in Emulate Docker CLI using podman. Create /etc/containers/nodocker to quiet msg. Wrapper này bao phủ các command bạn dùng hằng ngày: run, ps, logs, exec, build, pull, push, inspect, cp, volume, network.

Những gì không tương thích là một danh sách ngắn hơn nhưng quan trọng hơn. Swarm mode không có thành phần tương đương, nên không có nơi để chạy một Swarm stack. Các tool giao tiếp với Docker socket cần Podman socket được export, và một số tool vẫn nhận ra sự khác biệt này; Docker provider của Traefik hoạt động khi trỏ đến /run/user/<uid>/podman/podman.sock, còn Watchtower hoàn toàn không có vai trò tương đương vì podman auto-update đã xử lý việc đó. Storage được tách riêng, nên Podman không thể thấy các image bạn đã pull bằng Docker, và podman images trên một Docker host đang hoạt động sẽ bắt đầu ở trạng thái trống.

Di chuyển một stack đang chạy, từng bước

1. Tạo hoặc chọn user không có quyền đặc biệt để sở hữu các container, rồi xác nhận user này có range trong /etc/subuid.
2. Pull lại mọi thứ lấy từ registry bằng tên đầy đủ. Podman có image store riêng và sẽ không đọc image store của Docker.
3. Di chuyển các image build cục bộ bằng docker save app:1.4 | podman load.
4. Dừng container Docker, sao chép nội dung của từng volume ra khỏi /var/lib/docker/volumes/<name>/_data, rồi sửa ownership bằng podman unshare chown -R 1000:1000 <path>.
5. Xử lý vấn đề port: publish port lớn hơn 1024 phía sau reverse proxy, hoặc đặt net.ipv4.ip_unprivileged_port_start.
6. Viết một file quadlet cho mỗi container, chạy systemctl --user daemon-reload, rồi start từng service.
7. Chạy sudo loginctl enable-linger <user>, reboot VPS, đăng nhập lại và kiểm tra podman ps liệt kê lại đầy đủ mọi service.

Hai engine không dùng chung bất kỳ thành phần nào: image storage và network đều tách biệt. Vì vậy, bạn có thể chạy cả hai trong khi di chuyển. Thứ duy nhất chúng có thể tranh chấp là số port trên host. Di chuyển từng service, monitor trong 1 ngày, rồi chuyển service tiếp theo.

Podman và Docker: công cụ nào phù hợp với VPS của bạn?

Tiếp tục dùng Docker nếu stack của bạn nằm trong các file compose được nhiều người cùng duy trì, hoặc nếu bạn phụ thuộc vào các công cụ giao tiếp với Docker socket. Tương thích với định dạng mà mọi người cùng viết là một tính năng thực tế, và Docker có mức tương thích cao hơn. Nếu laptop của cả team đều chạy Docker, việc chạy cùng engine trong production cũng mang lại lợi ích rõ ràng.

Chuyển sang Podman nếu VPS chỉ chạy một vài service do bạn kiểm soát từ đầu đến cuối, hoặc nếu bạn muốn mỗi ứng dụng chạy dưới một user không có đặc quyền riêng và trên máy hoàn toàn không có group docker. Mức độ phù hợp với distribution cũng rất quan trọng: RHEL và các bản rebuild của RHEL phát hành Podman làm engine được hỗ trợ, nên trên các hệ thống đó Podman là lựa chọn có ít vấn đề bất ngờ hơn. Nếu vẫn muốn dùng Docker trên một trong các host đó, quy trình dnf trên Rocky Linux và AlmaLinux bắt đầu bằng việc xóa wrapper podman-docker đang sở hữu command docker trên hệ thống. Nếu bạn đã dùng systemd unit để quản lý mọi thứ khác, quadlet sẽ giống như mảnh ghép còn thiếu được bổ sung, thay vì một công cụ mới phải học.

Có một lựa chọn trung gian đáng nhắc đến. Podman chạy rootful hoạt động gần giống Docker, vẫn giữ command docker thông qua wrapper, đồng thời loại bỏ daemon luôn chạy nền. Tuy nhiên, cách này cũng bỏ qua mô hình rootless, vốn là phần thay đổi vị thế bảo mật của bạn, nên hãy xem đây là một bước chuyển tiếp.

Nếu bạn vẫn đang dựng container host đầu tiên, quy trình cài đặt và hardening Docker trên VPS mới là con đường ngắn hơn, và những kiến thức đó vẫn hữu ích. Image và volume là cùng một loại object trên cả hai engine, nên việc chuyển đổi sau này chủ yếu thay đổi cách service được systemd quản lý, còn hầu như không thay đổi điều gì khác.

FAQ

Podman có phải là bản thay thế trực tiếp cho Docker không?

Đối với các lệnh bạn nhập thì gần như có. Cài đặt podman-docker sẽ cung cấp wrapper /usr/bin/docker, còn run, ps, build, logs và exec hoạt động theo cùng cách. Tuy nhiên, đây không phải là bản thay thế cho daemon. Swarm không có thành phần tương đương, các công cụ kết nối đến /var/run/docker.sock phải được trỏ đến socket Podman theo từng user, và các image được Docker pull sẽ không hiển thị trong Podman vì hai công cụ dùng storage riêng.

Vì sao các container Podman rootless của tôi dừng khi tôi đăng xuất khỏi SSH?

Vì systemd dừng user session, cùng với mọi user service, khi phiên đăng nhập cuối cùng của bạn đóng. Chạy sudo loginctl enable-linger <user>, rồi kiểm tra để bảo đảm loginctl show-user <user> --property=Linger in ra Linger=yes. Linger giữ instance systemd của user đó chạy khi không có session đang hoạt động. Đây cũng là cơ chế giúp container khởi động lại sau reboot.

Vì sao các file trong volume của tôi thuộc về UID 100999?

Podman rootless ánh xạ container UID 0 vào user trên host, sau đó ánh xạ container UID 1 trở lên vào dải subuid của bạn. Với dải bắt đầu từ 100000, container UID 1000 trở thành 100999 trên host. Hãy sửa quyền từ bên trong namespace bằng podman unshare chown 1000:1000 /path/to/data, mount với flag :U trong lần chạy đầu tiên, hoặc dùng --userns=keep-id để UID của container khớp với UID của bạn.

Tôi có thể tiếp tục dùng docker-compose.yml với Podman không?

Có, theo 2 cách. podman-compose đọc file rồi điều khiển trực tiếp Podman CLI. Hoặc bật compatibility socket bằng systemctl --user enable --now podman.socket, đặt DOCKER_HOST=unix:///run/user/$(id -u)/podman/podman.sock, rồi chạy docker compose thật qua socket đó. Có thể phát sinh vấn đề với network_mode: host, với các service mount Docker socket, và với restart: always. Thành phần này cần một quadlet unit và linger để tiếp tục chạy sau reboot.

Rootless có thực sự làm container an toàn hơn không?

Rootless loại bỏ một rủi ro cụ thể: nếu một tiến trình thoát khỏi container rootless, tiến trình đó chỉ có quyền của user không đặc quyền của bạn thay vì quyền root. Đây là một lợi ích đáng kể. Vì vậy nhóm tương đương root là docker không có thành phần tương đương khi dùng Podman rootless. Rootless không ngăn được các lỗ hổng kernel và không bảo vệ những file mà chính user của bạn có thể đọc. Vì vậy, vẫn phải áp dụng các biện pháp hardening khác như khi vận hành bất kỳ server nào.