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

субота, 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

неділя, 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

Посилання

субота, 26 жовтня 2024 р.

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

 Задача

Нам всім потрібно час від часу зберігати свої власні напрацювання у вигляді конфігурацій, скриптів та і взагалі будь-яких своїх know-how, щоб у разі, якщо виникає задача, яку вже доводилося вирішувати, не намагатися напружено згадати, як воно було “того разу”, чи черговий раз шукати рішення в Інтернеті. Система керування версіями – Version Control System (VCS), є для цього практично ідеальним інструментом.

На сьогодні вибором VCS в 90% випадків є Git. Функціональність, зручність, поширеність і наявність доступних хмарних сервісів типу GitHub, GitLab, Bitbucket, та інших, як правило, є вирішальними факторами на користь Git. 

Встановлення git на Linux взагалі не становить суттєвої проблеми, наприклад, на Ubuntu достатньо виконання команд:

sudo apt update

sudo apt install git

Але я намагаюся встановлювати додаткову функціональність на своєму Virtual Private Server (VPS) на хостінгу, на своїх Linux робочих станціях і віртуальних машинах з максимальним використанням Docker контейнерів. Не буду поринати в доведення переваг такого підходу, головне те, що мені так цікавіше 🙂

Отже задача полягає у встановленні на сервер з Ubuntu 22.04 git у вигляді Docker контейнера. Потрібний для цього Docker Engine було встановлено раніше.

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

Шукаємо Docker образ на Docker Hub. По моделі git знаходимо низку образів, серед яких чільні місця з популярності і кількості завантажень займають alpine/git і bitnami/git.

alpine/git – простий git в середовищі Alpine Linux, яке забезпечує створення максимально компактних Docker образів.

bitnami/git – git в середовищі Minideb – адаптованої версії Debian Linux для побудови образів, від відомого розробника образів Bitnami (зараз є частиною VMWare, яка в свою чергу належить Broadcom). Серед Docker образів, які надає Bitnami: bitname/nginx, bitnami/wordpress, bitnami/mariadb і багато інших (пошук на Docker Hub по моделі bitnami дав 2 228 результатів).

В даному випадку мені потрібний саме простий компактний git з базовою функціональністю, відтак мій вибір – alpine/git

Насправді, я спробував обидва варіанти. bitnami/git роздратував об’ємом рекламного тексту, який з’являвся на екрані при кожному запуску. Думаю, що цього можна позбутися – перезібрати образ самотужки за допомогою Dockerfile, який наводиться, знайти і відредагувати entrypoint файл, чи щось подібне. Можливо, колись і це зроблю, але наразі alpine/git мене цілком влаштовує. 

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

Встановлення останньої (latest) версії Docker образу alpine/git:

chd@REBEL:~$ docker pull alpine/git

Using default tag: latest

latest: Pulling from alpine/git

43c4264eed91: Pull complete 

d376ed7606d9: Pull complete 

117123371baa: Pull complete 

Digest: sha256:888261e21bc4577e464d996f20cbf8eb8b0fa787491f62757530e4db46720d8b

Status: Downloaded newer image for alpine/git:latest

docker.io/alpine/git:latest


chd@REBEL:~$ docker images

REPOSITORY   TAG       IMAGE ID       CREATED       SIZE

alpine/git   latest    9fd7c1f96ff3   2 weeks ago   89.5MB


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


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

git version 2.45.2


Очевидно, що git працездатний, інформацію про версію ми отримали – 2.45.2.


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


function git () {

    (docker run -ti --rm -v ${HOME}:/root -v $(pwd):/git alpine/git "$@")

}


Відтак після входу в систему нам буде доступна команда git, яка буде запускати git контейнер.

Для того, щоб не виходити з поточної оболонки і вже актуалізувати команду git, виконуємо команду:

chd@REBEL:~$ source ~/.bash_profile

Перевіряємо нову команду:

chd@REBEL:~$ git version

git version 2.45.2


Для подальшого тестування можемо склонувати з GitHub репозиторій doctorchd/doctorvirt:

chd@REBEL:~$ mkdir git

chd@REBEL:~$ cd git

chd@REBEL:~/git$ git clone https://github.com/doctorchd/doctorvirt.git

Cloning into 'doctorvirt'...

remote: Enumerating objects: 3, done.

remote: Counting objects: 100% (3/3), done.

remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0)

Receiving objects: 100% (3/3), done.


chd@REBEL:~/git$ cd doctorvirt

chd@REBEL:~/git/doctorvirt$ git status

On branch main

Your branch is up to date with 'origin/main'.


nothing to commit, working tree clean

Посилання