Показ дописів із міткою Virtualization. Показати всі дописи
Показ дописів із міткою Virtualization. Показати всі дописи

субота, 12 квітня 2025 р.

Додаток до лабораторної роботи 8. Встановлення Docker Desktop і helm в Windows

Цей додаток до лабораторної роботи 8 адресований студентам, на чиїх компʼютерах встановлено операційну систему Windows. В додатку пояснюється, як на компʼютері з Windows встановити пакунки Docker Desktop  і helm. Ці пакунки необхідні для виконання лабораторної роботи 8 “Знайомство з Kubernetes за допомогою Docker Desktop”.

Для встановлення менеджера пакунків для Kubernetes (чартів) використовується менеджер пакунків для Windows scoop, встановлення якого також описано в даному додатку. scoop в операційній системі Windows виконує роль, яка подібна до ролі інструментарія Home Brew в операційній системі MacOS.

Керівництво з виконання роботи, PDF

YouTube


понеділок, 7 квітня 2025 р.

Лабораторна робота 8. Знайомство з Kubernetes

Kubernetes – є ефективною платформою оркестрації для програмних систем на основі контейнерів.

В якості бази для розгортання Kubernetes використовує кластер виконавчих вузлів – Worker nodes, який функціонує під керуванням вузлів управління – Master nodes. Використання кластерної бази забезпечує загальну високу доступність системи, відсутність єдиної точки відмови, а також виключну здатність до масштабування.

Особливістю Kubernetes є застосування концепції просторів імен (namespaces), завдяки якій на одному кластері є могливість незалежного розгортання будь-якої кількості застосувань, кожне в індивідуальному просторі імен. Наявність програмних інтерфейсів – API, для керування всіма компонентів Kubernetes створює умови для інтеграції з зовнішніми системами, зокрема системами керування, моніторингу, безпеки, а також надає можливість розширення функціональності Kubernetes шляхом додавання компонентів, інтегрованих в інфраструктуру Kubernetes.

Базовим принципом розгортання і керування застосуваннями в Kubernetes є декларативне управління. Створення або зміна будь-якого обʼєкта в системі здійснюється за допомогою застосування декларацій (або маніфестів) – специфікацій кожного обʼєкта, які визначають бажану конфігурацію і стан цих обʼєктів.

Для автоматизації складного процесу розгортання програмних систем в Kubernetes широко використовується менеджер пакунків (так званих чартів) helm.

Docker Desktop – інструментарій керування Docker контейнерами на персональному компʼютері, який також реалізує обмежений функціонал Kubernetes.

субота, 29 березня 2025 р.

[Оновлено] Лабораторна робота 7. Розгортання застосування за допомогою Docker Compose

Docker Compose є додатком (плагіном) до базового інструментарію Docker, яке розширює функціональність Docker і дозволяє визначати і запускати системи з декількома контейнерами – мультиконтейнерні застосування.

Окрім контейнерів, які є базою для створення сервісів (services), Docker Compose оперує томами сховищ даних (volumes) і мережами (networks). Тома сховищ даних використовуються для збереження даних між запусками контейнерів і монтуються як частини файлових систем контейнерів. Мережі використовуються для організації взаємодії між контейнерами.

Вся конфігурація мультиконтейнерного застосування визначається вмістом файлу docker-compose.yml. 

Керівництво з виконання роботи, PDF

YouTube

субота, 22 березня 2025 р.

[Оновлення] Лабораторна робота 6. Створення образу для запуску Docker-контейнера

Контейнери -- процеси, які запускаються в середовищах, ізольованих від середовищ інших процесів Linux-системи. Елементом такого середовища є файлова система. Призначенням образу (image) для запуску Docker-контейнерів (або Docker-образу) є забезпечення ізольованої файлової системи для запуску контейнерів. 

Docker-образ є незмінним об’єктом, його можна порівняти з CD-диском для інсталяції операційної системи. Протягом життя контейнера (а це час життя відповідного процесу, який було запущено в ізольованому середовищі) можливе внесення змін в файлову систему, яку він використовує. Втім після завершення процесу і відповідно зупинки контейнера ці зміни будуть втрачені -- наступний контейнер, запущений з того самого образу, не міститиме змін файлової системи.

Для внесення постійних змін в файлову систему контейнерів можливо створення оновленого Docker-образу на основі попереднього “базового” образу. Після побудови нового образу він так само є незмінним об’єктом, який може використовуватися для запуску контейнерів. Побудова нового образу на основі базового образу описується в файлі Dockerfile.

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

субота, 15 березня 2025 р.

[Оновлення] Лабораторна робота 5. Знайомство з інструментарієм Docker

Контейнери -- спосіб запуску процесів в Linux-системі, який забезпечує їх ізоляцію від інших процесів системи. Інструментарій Docker забезпечує простий і ефективний спосіб керування всіма аспектами життєвого циклу Linux контейнера – створення, зупинка, запуск додаткових процесів, моніторинг і т.п.

Для запуску Docker контейнера необхідним є Docker образ (image). Базові образи, які безпосередньо можуть бути використані для запуску контейнерів, можуть бути завантажені з Docker репозиторіїв, таких як Docker Hub.

Дана робота надає досвід виконання базових дій з інструментарієм Docker – завантаження Docker образів, запуск і зупинка контейнерів, перегляд інформації про них. 

В роботі використовується віртуальна машина Ubuntu Linux, яка була створена в попередніх роботах за допомогою гіпервізорів Oracle VirtualBox або UTM.

Керівництво з виконання роботи, PDF

YouTube

неділя, 9 березня 2025 р.

[Оновлення] Лабораторна робота 4. Знайомство з технологією Linux контейнерів

Контейнери -- спосіб запуску процесів в Linux-системі, який забезпечує їх ізоляцію від інших процесів системи. Технологія створення контейнерів базується на функціональності просторів імен (name spaces) ядра Linux.

Процес, який виконується в окремому просторі імен, відрізняється від інших процесів в системі лише тим, що він “не бачить” процеси за межами свого простору імен, тоді як система “бачить” цей процес в переліку всіх процесів, які в ній виконуються.

В окремому просторі імен можна запустити як один, так і декілька процесів. При цьому ці процеси “бачать” лише один одного і “не бачать” процеси за межами їх простору імен.

У разі зупинки процесу під час запуску якого було створено окремий простір імен автоматично зупиняються всі інші процеси, які виконувалися в цьому просторі імен.

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

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

В роботі використовується віртуальна машина Ubuntu Linux, яка була створена в лабораторній роботі “Створення віртуальної машини Ubuntu Linux за допомогою Oracle VirtualBox”. 

Керівництво з виконання роботи, PDF

YouTube

Додаток до лабораторної роботи 3. Мережеве підключення віртуальної машини у разі використання гіпервізора UTM на платформі MacOS

Цей додаток до лабораторної роботи 3 адресований студентам з компʼютерами MacBook з процесорами M1, M2, M3. На цих компʼютерах в лабораторних роботах в якості гіпервізора використовується UTM.

Дана робота надає досвід організації мережевого доступу до сервісів на віртуальній машині, створеній за допомогою гіпервізора UTM на платформі MacOS. Прикладами сервісів є SSH та HTTP.

Сервер OpenSSH є найпоширенішим програмним продуктом з відкритим кодом для організації з’єднань з використанням протоколу Secure Shell (SSH). Протокол SSH забезпечує захищену передачу даних через мережу за допомогою потужних алгоритмів криптування. Протокол SSH масово використовується для віддаленого адміністрування систем і пристроїв.

Веб сервер Apache є поширеним програмним продуктом з відкритим кодом для створення сервісів HTTP(S).

Керівництво з виконання роботи, PDF

YouTube

[Оновлення] Лабораторна робота 3. Мережеве підключення віртуальної машини

Дана робота надає досвід організації мережевого доступу до сервісів на віртуальній машині, створеній за допомогою гіпервізора Oracle VirtualBox. Прикладами сервісів є SSH та HTTP.

Сервер OpenSSH є найпоширенішим програмним продуктом з відкритим кодом для організації з’єднань з використанням протоколу Secure Shell (SSH). Протокол SSH забезпечує захищену передачу даних через мережу за допомогою потужних алгоритмів криптування. Протокол SSH масово використовується для віддаленого адміністрування систем і пристроїв.

Веб сервер Apache є поширеним програмним продуктом з відкритим кодом для створення сервісів HTTP(S).

Керівництво з виконання роботи, PDF

YouTube

неділя, 23 лютого 2025 р.

Додаток до лабораторних робіт 1-2. Встановлення гіпервізора UTM і віртуальної машини Ubuntu Linux в системі MacOS

Цей додаток до лабораторних робіт 1 та 2 адресований студентам з компʼютерами MacBook з процесорами M1, M2, M3. На цих компʼютерах неможливо використання гіпервізора Oracle VirtualBox як на Windows або Linux. В якості гіпервізора на них може бути використаний UTM. На відміну від VirtualBox UTM здатен емулювати в системі з процесорами з архітектурою ARM середовище системи з процесором x86. Функціонування в режимі емуляції призводить до певної втрати продуктивністі, але для наших задач це прийнятно.
UTM є повнофункціональним гіпервізором для використання в операційних системах iOS і macOS. Початково базувався на гіпервізорі QEMU. Надає можливість запуску операційних систем, призначених для платформ на основі Intel-сумісних процесорів (з архітектурою x86), в вивстемах, які використовують процесори з архітектурою ARM.

[Оновлення] Лабораторна робота 2. Створення віртуальної машини Ubuntu Linux за допомогою Oracle VirtualBox

Дана робота надає досвід роботи з гіпервізором Oracle VirtualBox та встановлення ВМ під керуванням ОС Ubuntu Linux.

ОС Ubuntu Linux є одним з лідерів за поширенням на серверах застосувань підприємств та провайдерів Інтернет-послуг. Базова частина Ubuntu є безкоштовним продуктом та містить компоненти лише з відкритим вихідним кодом.

Керівництво з виконання роботи, PDF

YouTube

[Оновлення] Лабораторна робота 1. Встановлення гіпервізора Oracle VirtualBox в системі Windows11

Технологія віртуалізації, яка відома з 1960-х років, здобула надзвичайне поширення протягом останніх 10 років в наслідок появи мікроелектронної компонентної бази, що дозволяє створювати віртуальні застосування майже без втрати ефективності порівняно з традиційною реалізацією застосувань. Продуктивність сучасних віртуальних машин (ВМ) близька до продуктивності реальних (фізичних) серверів, а гнучкість і технологічність ВМ зумовлює їх масове використання у сучасних інформаційних проектах. Масовість створюваних віртуальних об’єктів та поява розвинутих засобів динамічного керування ними призвело до появи технології хмарних обчислень.

Основою технології використання є гіпервізор — програмне забезпечення, що
встановлюється як застосування в операційній системі (ОС) фізичного сервера-носія та
створює умови подібні до апаратної платформи з заданими параметрами (обсяг і тип
ресурсів — процесор, оперативна пам’ять, жорсткий диск, мережеві адаптери). На
створеній віртуальній платформі можливе встановлення гостьової ОС та застосувань в
ній.

Дана робота надає досвід встановлення гіпервізора Oracle VirtualBox в операційній
системі Windows11.

Керівництво з виконання роботи, PDF 

неділя, 24 листопада 2024 р.

Встановлення Ansible в Docker контейнері

Задача

Ansible – програмний продукт з відкритим кодом, який є зручним інструментом виконання дій паралельно на компонентах великих систем. Компоненти можуть бути на будь-яких платформах – Linux/Unix, мережеві пристрої різних виробників типу Cisco, Juniper, системи на хмарних платформах типу AWS, Azure і т.п. Головна умова – компоненти повинні забезпечити доступ по SSH. Виконання сценаріїв (playbooks) Ansible може застосовуватися для розгортання систем і для виконання широкого спектру задач з автоматизації, можна вважати, що Ansible є одним з можливих інструментів реалізації концепції Infrastructure as Code (IaC), хоча для забезпечення ідемпотентності потрібні певні зусилля.

Для окремого хоста Ansible є зручним інструментом для розгортання і автоматизації. За умови максимального використання Docker для інсталяції пакунків (про яке було зазначено в дописі Встановлення Docker на Linux сервері) розгортання хоста в певній наперед заданій конфігурації може виглядати, наприклад, таким чином:

  • інсталяція мінімальної операційної системи (ОС)

  • інсталяція Docker

  • інсталяція Git в Docker

  • інсталяція Ansible в Docker

  • клонування Git-репозиторію зі сценаріями Ansible

  • виконання сценаріїв Ansible

Отже наша задача сьогодні – встановлення Ansible в Docker контейнері на сервері з Ubuntu 22.04.

Інформаційний пошук

Для пошуку Docker образу Ansible відвідуємо Docker Hub. Пошук по моделі ansible видає тисячи результатів. При сортуванні за найкращим співпадінням – Best Match, яке застосовується за замовчуванням, серед результатів, які відображаються на екрані (перші 25) звертаємо увагу на дату останнього оновлення (образи, які останній раз оновлювалися декілька років тому, нас не цікавлять), кількість завантажень і кількість зірочок. Найбільш привабливим виглядає alpine/ansible. Додатковим аргументом для використання цього образу є те, що ми вже використовували образ Git від цього постачальника.

Встановлення Ansible і налаштування для використання

В описі образу alpine/ansible надане посилання на Dockerfile, за допомогою якого було побудовано цей образ:

FROM alpine:3


RUN apk add --update --no-cache ansible bash openssh sshpass


ENTRYPOINT []

CMD ["ansible", "--help"]


Недоліком тут є те, що команди, які передаються в контейнер в якості ENTRYPOINT, виконуються в кореневому каталозі (/). Нам потрібно, щоб робочим каталогом був поточний каталог, в якому буде запускатися ansible контейнер. Отже образ потрібно змінити. Створюємо свій Dockerfile на основі наведеного для alpine/ansible, в якому створюємо і визначаємо в якості робочого каталог /work:


chd@REBEL:~$ mkdir -p docker/ansible

chd@REBEL:~$ cd docker/ansible

chd@REBEL:~$ vi Dockerfile


FROM alpine:3


RUN apk add --update --no-cache ansible bash openssh sshpass \

&& mkdir -p /work


WORKDIR /work


ENTRYPOINT []

CMD ["ansible", "--help"]


Будуємо новий образ з іменем ansible:


chd@REBEL:~/docker/ansible$ docker build -t ansible .

[+] Building 16.8s (7/7) FINISHED                         docker:default

 => [internal] load build definition from Dockerfile                0.0s

 => => transferring dockerfile: 196B                                0.0s

 => [internal] load metadata for docker.io/library/alpine:3         0.8s

 => [internal] load .dockerignore                                   0.0s

 => => transferring context: 2B                                     0.0s

 => CACHED [1/3] FROM docker.io/library/alpine:3@sha256:1e42bbe2…   0.0s

 => [2/3] RUN apk add --update --no-cache ansible bash openssh …    9.8s

 => [3/3] WORKDIR /work                                             0.0s

 => exporting to image                                              6.1s

 => => exporting layers                                             6.1s

 => => writing image sha256:652494262c5b24cd5c0221f60851d2114538…   0.0s

 => => naming to docker.io/library/ansible                          0.0s


chd@REBEL:~/docker/ansible$ docker images

REPOSITORY   TAG       IMAGE ID       CREATED          SIZE

ansible      latest    652494262c5b   45 seconds ago   410MB

alpine/git   latest    507906c82962   7 days ago       89.5MB


Перевірка працездатності ansible контейнера – відображення версії ansible:


chd@REBEL:~/docker/ansible$ docker run -it --rm --name ansible ansible ansible --version

ansible [core 2.17.0]

…


Ansible працездатний, поточна версія – 2.17.0.

Пересвідчуємося, що в якості робочого каталогу використовується /root:


chd@REBEL:~/docker/ansible$ docker run -it --rm --name ansible ansible pwd

/work


Для зручності використання додамо наступні рядки до файлу ~/.bash_aliases (якщо цей файл відсутній, можна його створити):


alias ansible='docker run -it --rm --name ansible -v ${HOME}:/root -v $(pwd):/work ansible ansible'


alias ansible-playbook='docker run -it --rm --name ansible-playbook -v ${HOME}:/root -v $(pwd):/workansible ansible-playbook'


В наведених командах домашній каталог монтується в контейнері як /root, а поточний – як /work.


Примітка: типово в файлі .bashrc знаходяться наступні рядки, які забезпечують виконання файлу .bash_aliases при початку нової bash сесії:


if [ -f ~/.bash_aliases ]; then

    . ~/.bash_aliases

fi


Для актуалізації нових псевдонімів (aliases) викоуємо команду:


chd@REBEL:~$ source ~/.bashrc


Перевіряємо працездатність нових команд:


chd@REBEL:~$ ansible --version

ansible [core 2.17.0]

…


chd@REBEL:~$ ansible -m ping localhost

[WARNING]: No inventory was parsed, only implicit localhost is available

localhost | SUCCESS => {

    "changed": false,

    "ping": "pong"

}


chd@REBEL:~$ ansible-playbook --version

ansible-playbook [core 2.17.0]

…


Для перевірки команди ansible-playbook створюємо тестовий сценарій test.yaml:


chd@REBEL:~$ mkdir ansible

chd@REBEL:~$ cd ansible

chd@REBEL:~/ansible$ vi test.yaml 

                                                                                      

- hosts: localhost

  gather_facts: no


  tasks:

    - ping:


chd@REBEL:~/ansible$ ansible-playbook test.yaml

[WARNING]: No inventory was parsed, only implicit localhost is available

[WARNING]: provided hosts list is empty, only localhost is available. Note that the implicit localhost does not match 'all'


PLAY [localhost] *******************************************************


TASK [ping] ************************************************************

ok: [localhost]


PLAY RECAP *************************************************************

localhost   : ok=1 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0

Посилання