Встановлення Docker та Docker Compose на Ubuntu

Docker на Ubuntu має сенс ставити не як випадковий набір команд з різних форумів, а як повторювану базову конфігурацію, яку можна без сюрпризів використати на локальному стенді, тестовому сервері або staging-вузлі. Більшість проблем з Docker починаються не з самого `docker run`, а з дрібниць: неправильний репозиторій, змішані пакети з дистрибутива та офіційного джерела, відсутні права для користувача, невірний шлях до volume-даних або плутанина між класичним `docker-compose` і плагіном `docker compose`.

У цій статті розберемо встановлення Docker Engine та Docker Compose на Ubuntu актуальним способом через офіційний репозиторій Docker, а також базову перевірку, роботу з сервісом, групами доступу, Compose-файлом і типовими помилками. Такий базовий підхід добре вкладається в процеси, де далі підключаються DevOps послуги, автоматизація через CI/CD і більш складні сценарії оркестрації, зокрема в уже опублікованому матеріалі про встановлення Kubernetes на Ubuntu 24.04. Якщо Docker ставиться акуратно з першого разу, далі простіше будувати передбачуване середовище для застосунків, reverse proxy, worker-процесів і службових контейнерів.

Що варто підготувати перед встановленням

Для базової інсталяції достатньо чистої Ubuntu, користувача з `sudo` та доступу до мережі. Але навіть у простому сценарії корисно одразу визначити, навіщо саме ставиться Docker. Якщо це локальний сервер під кілька контейнерів, можна обмежитися мінімальною конфігурацією. Якщо це вузол для регулярних оновлень, збірок або службових сервісів, краще відразу налаштувати окремі каталоги під дані, зрозумілу схему імен контейнерів і контроль доступу для користувачів.

Перед інсталяцією бажано перевірити:

- версію Ubuntu - наявність старих пакетів Docker з репозиторію дистрибутива - чи не використовується сервер уже під інший container runtime - чи вистачає місця на диску для image layers і volume-даних

Швидка перевірка виглядає так:

lsb_release -a
uname -r
df -h
apt list --installed | grep -E 'docker|containerd'

Якщо раніше на вузлі вже встановлювався Docker з іншого джерела, краще одразу прибрати конфліктні пакети, інакше далі легко отримати плутанину з версіями клієнта, демона або плагінів.

Підключення офіційного репозиторію та встановлення Docker

Для Ubuntu рекомендовано ставити Docker через офіційний репозиторій Docker, а не через системний пакет `docker.io`, якщо потрібна передбачувана актуальна версія. Спочатку видаляємо старі або конфліктні пакети, а потім додаємо ключ і репозиторій.

sudo apt remove -y docker.io docker-doc docker-compose docker-compose-v2 podman-docker containerd runc
sudo apt update
sudo apt install -y ca-certificates curl gnupg

sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg \
  | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
  $(. /etc/os-release && echo \"$VERSION_CODENAME\") stable" \
  | sudo tee /etc/apt/sources.list.d/docker.list >/dev/null

sudo apt update

Після цього корисно переконатися, що `apt` вже бачить пакети саме з офіційного джерела, а не з базового репозиторію Ubuntu:

apt-cache policy docker-ce docker-ce-cli docker-compose-plugin

Якщо вивід показує `download.docker.com`, можна переходити до встановлення. Якщо ні, краще зупинитися й перевірити GPG-ключ, codename релізу та файл `docker.list`.

Встановлення Docker Engine та Compose plugin

У сучасному сценарії Docker Compose ставиться не окремим старим Python-пакетом, а як plugin `docker-compose-plugin`. Саме тому після встановлення працює команда `docker compose`, а не `docker-compose`.

sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Після встановлення потрібно одразу перевірити, що демон стартував і переживає перезапуск:

sudo systemctl enable docker
sudo systemctl start docker
sudo systemctl status docker --no-pager

Потім дивимося версію клієнта, демона і Compose plugin:

docker version
docker compose version

Якщо `docker compose version` повертає нормальний номер версії, значить plugin підключився правильно. Якщо команда не знайдена, зазвичай це означає, що встановлено старий пакет або Compose plugin не дотягнувся з репозиторію.

Налаштування доступу без sudo

За замовчуванням Docker daemon слухає Unix socket, і працювати з ним без `sudo` можна тільки після додавання користувача в групу `docker`. Це зручно, але потрібно пам'ятати: доступ до Docker фактично еквівалентний розширеним системним правам на вузлі. Тому таке налаштування підходить лише для довірених користувачів.

sudo usermod -aG docker $USER
newgrp docker

Після цього перевірка виглядає так:

docker ps
docker run --rm hello-world

Контейнер `hello-world` не має практичної цінності сам по собі, але швидко підтверджує, що клієнт бачить daemon, image завантажується, а runtime справді може підняти контейнер.

Що перевірити одразу після першого запуску

Після базового тесту корисно перевірити ще кілька речей, які часто пропускають на першому етапі:

- шлях зберігання образів і контейнерів - чи працює автоматичний старт сервісу після reboot - чи не заблокований Docker локальними firewall-правилами, якщо далі будуть публічні порти - чи достатньо місця під volume-дані

Базові команди:

docker info
sudo systemctl is-enabled docker
sudo du -sh /var/lib/docker

Якщо сервер готується під кілька сервісів, краще відразу продумати моніторинг, очищення старих image layers і політику оновлення контейнерів, а не чекати моменту, коли диск раптово закінчиться.

Як створити перший docker compose файл

Після встановлення Docker зручно одразу перевірити Compose на реальному прикладі. Найпростіший сценарій це один контейнер Nginx з пробросом порту. Створюємо окремий каталог проєкту й файл `compose.yaml`.

mkdir -p ~/docker/nginx-demo
cd ~/docker/nginx-demo

cat > compose.yaml <<'EOC'
services:
  nginx:
    image: nginx:1.27
    container_name: nginx-demo
    restart: unless-stopped
    ports:
      - "8080:80"
    volumes:
      - ./html:/usr/share/nginx/html:ro
EOC

mkdir -p html
echo '<h1>Docker Compose works</h1>' > html/index.html

Після цього контейнер запускається так:

docker compose up -d
docker compose ps
curl http://127.0.0.1:8080

Якщо `curl` повертає HTML-сторінку, Compose-файл працює коректно: container стартував, порт опублікований, volume підмонтувався, а сервіс відповідає назовні.

Практичні команди для повсякденної роботи

Після інсталяції користь від Docker з'являється лише тоді, коли є набір базових команд для повсякденної експлуатації. Найчастіше потрібні перевірка контейнерів, логи, перезапуск, зупинка і прибирання непотрібних ресурсів.

docker ps -a
docker logs -f nginx-demo
docker compose restart
docker compose down
docker image ls
docker volume ls

Для безпечного очищення непотрібних ресурсів зручно використовувати:

docker system df
docker system prune -f

Але команду `docker system prune` не варто запускати навмання на вузлі, де вже є робочі контейнери, потрібні stopped-контейнери або кеші збірки. Перед очищенням краще розуміти, що саме видаляється.

Типові помилки

Найтиповіша помилка це змішування пакетів: частина ставиться з Ubuntu, частина з офіційного репозиторію Docker. Друга проблема це очікування, що `docker-compose` і `docker compose` це одне й те саме в усіх сценаріях. У сучасній Ubuntu штатний варіант це саме plugin-команда `docker compose`. Третя помилка це робота тільки через `sudo`, а потім нерозуміння, чому звичайний користувач не може запускати контейнери. Четверта це відсутність перевірки диска й каталогів `/var/lib/docker`, через що після кількох image pull або rebuild закінчується місце. П'ята це публікація портів без розуміння, які сервіси реально стають доступними ззовні.

Окремо часто помиляються з Compose-файлами. Наприклад, пробують монтувати volume в каталог, який ще не існує, плутають `restart: always` і `restart: unless-stopped`, або запускають `docker compose down -v`, не розуміючи, що це прибирає пов'язані volumes разом з даними.

Висновок

Встановлення Docker та Docker Compose на Ubuntu краще робити через офіційний репозиторій Docker, з чистою схемою пакетів, увімкненим системним сервісом і відразу зрозумілою перевіркою через реальний контейнер та Compose-файл. Такий підхід зменшує кількість прихованих проблем на старті й робить середовище придатним для подальшої автоматизації, збирання образів, тестових запусків і стабільного деплойменту сервісів.

Практичний наступний крок після базової інсталяції це не просто запуск ще одного контейнера, а нормалізація роботи з конфігураціями: окремі каталоги, контроль змін у git, Compose-шаблони, політика логів, секретів і оновлень. Саме тоді Docker перестає бути тимчасовою утилітою й стає керованим інструментом для інфраструктури, застосунків і сервісного контуру.