Підготовка трьох Ubuntu Server

Після модуля ви зможете підготувати й прийняти три однорідні Ubuntu Server вузли для Swarm: перевірити identity, стабільну мережу, SSH, час, ресурси, Docker Engine та адміністративний доступ до зміни стану кластера.

• кожен вузол має унікальні hostname та machine identity
• cluster0 використовує стабільну адресу окремої мережі
• час синхронізовано до операцій Raft і TLS
• версії Engine та plugins збігаються
• passwordless sudo перевіряється без інтерактивного запиту
• початкову capacity зафіксовано до розміщення workloads

Кожна VM має DHCP uplink для пакетів і окремий cluster0 у мережі 10.77.0.0/24. Swarm advertise address і data-path address мають використовувати cluster0, щоб зміна DHCP uplink не змінювала identity вузла та overlay transport.

Три VM зменшують залежність від однієї guest OS або Engine, але працюють на одному Windows-хості. Відмова живлення, Hyper-V, фізичного адаптера або диска хоста залишається спільним failure domain.

Відмінності kernel, Engine, firewall, MTU, clock або package state створюють несиметричні відмови: task працює на двох nodes і падає на третьому. До join формують baseline і порівнюють факти, а не лише наявність команди docker.

• hostname та адреси визначають спостережувану identity
• NTP захищає строки сертифікатів і порядок подій
• однакова версія Engine зменшує відмінності API та поведінки
• package hold запобігає незапланованому version skew
• вільні CPU, RAM і disk задають початкову capacity

Лабораторія використовує key-only SSH, вимкнені password і root login та passwordless sudo для виділеного користувача swarmlab. Приватний ключ залишається на devops-vm. ProxyJump через Windows надає доступ до internal switch, не публікуючи SSH manager-вузлів у домашню LAN.

Passwordless sudo припустимий для ізольованої навчальної VM, але потребує захисту приватного ключа. У production область sudo та SSH principals проєктують окремо.

• Запускайте однакову перевірку на всіх трьох вузлах і порівнюйте вивід
• Не виправляйте один вузол до збереження evidence про відмінність
• Не публікуйте cluster ports 2377, 7946 та 4789 у LAN
• Перевіряйте sudo командою sudo -n true, щоб тест не завис
• Розділяйте DHCP uplink і стабільний cluster0
• Не оновлюйте Engine на одному manager поза процедурою rolling maintenance

Перевірте hostname й адреси. Очікуються cluster0: 10.77.0.11, 10.77.0.12 та 10.77.0.13; uplink адреси можуть змінюватися.

ssh swarm-manager-1 hostnamectl
ssh swarm-manager-2 hostnamectl
ssh swarm-manager-3 hostnamectl
ssh swarm-manager-1 ip -4 -br address
ssh swarm-manager-2 ip -4 -br address
ssh swarm-manager-3 ip -4 -br address

Порівняйте client/server versions, переконайтеся в активності базових сервісів і перевірте неінтерактивне підвищення прав.

ssh swarm-manager-1 docker version
ssh swarm-manager-2 docker version
ssh swarm-manager-3 docker version
ssh swarm-manager-1 systemctl is-active docker chrony ssh
ssh swarm-manager-2 systemctl is-active docker chrony ssh
ssh swarm-manager-3 systemctl is-active docker chrony ssh
ssh swarm-manager-1 sudo -n true
ssh swarm-manager-2 sudo -n true
ssh swarm-manager-3 sudo -n true

ssh swarm-manager-1 timedatectl
ssh swarm-manager-2 timedatectl
ssh swarm-manager-3 timedatectl
ssh swarm-manager-1 chronyc tracking
ssh swarm-manager-2 chronyc tracking
ssh swarm-manager-3 chronyc tracking

Перевірте двосторонню зв’язність cluster0, потім зафіксуйте sockets, membership, CPU, пам’ять, диск та утримувані версії пакетів.

ssh swarm-manager-1 ping -c 2 10.77.0.12
ssh swarm-manager-1 ping -c 2 10.77.0.13
ssh swarm-manager-2 ping -c 2 10.77.0.11
ssh swarm-manager-2 ping -c 2 10.77.0.13
ssh swarm-manager-3 ping -c 2 10.77.0.11
ssh swarm-manager-3 ping -c 2 10.77.0.12
ssh swarm-manager-1 ss -lntup
ssh swarm-manager-1 docker node ls

ssh swarm-manager-1 nproc
ssh swarm-manager-1 free -h
ssh swarm-manager-1 df -h /
ssh swarm-manager-2 nproc
ssh swarm-manager-2 free -h
ssh swarm-manager-2 df -h /
ssh swarm-manager-3 nproc
ssh swarm-manager-3 free -h
ssh swarm-manager-3 df -h /
ssh swarm-manager-1 apt-mark showhold
ssh swarm-manager-2 apt-mark showhold
ssh swarm-manager-3 apt-mark showhold

Діагностику ведіть від transport до service. SSH verbose показує ProxyJump і ключ; networkctl та journal пояснюють адресу; chronyc — джерело й offset; systemd і Docker journal — запуск Engine.

ssh -vv swarm-manager-1 true
ssh swarm-manager-1 networkctl status cluster0
ssh swarm-manager-1 journalctl -u systemd-networkd --since today
ssh swarm-manager-1 systemctl status chrony
ssh swarm-manager-1 chronyc sources -v
ssh swarm-manager-1 systemctl status docker
ssh swarm-manager-1 journalctl -u docker --since today
ssh swarm-manager-1 docker info

• Host key verification failed потребує перевірити identity вузла, а не видаляти known_hosts навмання
• sudo: a password is required означає неправильний cloud-init baseline
• NTPSynchronized=no потребує виправити time source до failure drills
• різні Server Version потребують узгодженого maintenance
• немає зв’язку cluster0 — перевірте switch, IP/prefix і host firewall до Swarm ports

• Чому advertise address не можна прив’язувати до випадкового DHCP uplink?
• Які ризики створює розсинхронізація часу?
• Чому збігу docker --version недостатньо?
• Що доводить sudo -n true?
• Які відмови не покриває лабораторія на одному фізичному хості?
• Які порти потрібні Swarm між вузлами?

Модуль засвоєно, якщо ви можете надати порівняльний preflight трьох вузлів, пояснити кожне відхилення й не переходите до cluster changes за невідомої мережі, часу або version skew.

Лабораторія read-only і не створює ресурсів. Cleanup обмежений підтвердженням відсутності тестових services та збереженням здорового membership.

ssh swarm-manager-1 docker service ls
ssh swarm-manager-1 docker node ls