</pre>
<h1 id="16.virtualisation">16. Wirtualizacja</h1>
<p>
- Same pojęcie tego, że coś jest <em>wirtualne</em> odności się do
+ Same pojęcie tego, że coś jest <em>wirtualne</em> odnosi się do
translacji warstwy bazowej do postaci uproszczonego interfejsu, z
którego może korzystać wielu odbiorców. Z pojęciem wirtualizacji
zapoznaliśmy się pośrednio przy poznawaniu zagadnienia
</p>
<h2 id="16.1.virtualmachines">16.1. Maszyny wirtualne</h2>
<p>
- Maszyny wirtualne obejmują całość sprzętu komputerowego, za pomocą
- oprogramowania, wydzielane są zasoby fizycznego hosta oraz
+ Maszyny wirtualne obejmują całość sprzętu komputerowego za pomocą
+ oprogramowania. Wydzielane są zasoby fizycznego hosta oraz
tworzone nowe urządzenia aby powstała zupełnie nowa maszyna. Z
terminu <em>maszyna wirtualna</em>, korzysta się od wielu lat,
dlatego też w celach rozróżnienia (przecież spotkaliśmy się z
</p>
<p>
Żeby tego było mało, to możemy wróżnić jeszcze maszyny oparte
- całkowicie na oprogramowania, czyli <strong>emulatory</strong>. Przy
+ całkowicie na oprogramowaniu, czyli <strong>emulatory</strong>. Przy
użyciu tego rozwiązania możemy uruchamiać np. programy nieprzeznaczone
- domyślnie na wykorzystywaną przez nas architetkurę. Dla przykładu
+ domyślnie na wykorzystywaną przez nas architekturę. Dla przykładu
mamy obecnie dostępne emulatory konsol do gier czy smartfonów.
</p>
<h3 id="16.1.1.hypervisors">16.1.1 Hipernadzorcy</h3>
<p>
Innym ważnym zagadnieniem związanym z maszynami wirtualnymi jest
dostęp do procesora. Jak pamiętamy w systemie operacyjnym mamy dwa
- trybu dystępu do procesora. Tryb <em>jądra</em> - pozwalający na
+ trybu dostępu do procesora. Tryb <em>jądra</em> - pozwalający na
wykonanie dowolnych czynności oraz tryb <em>użytkownika</em> -
najprościej rzecz ujmując - ograniczony. Jeśli mamy uruchmiać na
maszynach systemy operacyjne, to hipernadzorcy powinni być
<h2 id="16.2.containers">16.2. Kontenery</h2>
<p>
Kontenery w przeciwieństwie do maszyn wirtualnych nie są tak
- odizolowane systemu hosta. Często swoą wykorzystywane jako prostsza
+ odizolowane od systemu hosta. Często są wykorzystywane jako prostsza
alternatywa. Kontenery korzystają z rozwiązań dostępnych już
w systemie, aby zapewnić swój rodzaj wirtualizacji. Najczęściej
- korzystają zmożliwości zmiany katalogu głównego (<em>chroot</em>)
+ korzystają z możliwości zmiany katalogu głównego (<em>chroot</em>)
oraz określenia limitów jądra (<em>rlimit</em>).
<strong>Kontener</strong> można określić jako ograniczone środowisko
uruchomieniowe przeznaczone dla zbioru procesów. Oznacza to, że mogą
<strong>wirtualizacji na poziomie systemu operacyjnego</strong>.
</p>
<p>
- Warto dodać, że nie ważna jest liczba kontenerów dalej host będzie
- dysponowować tylko własnym bazowym jądrem. Natomiast procesy
- użytkownika mogą pochodzić z innych dystrybucji niż bazowa.
+ Kontenery uruchomione w systemie hosta, będą wspołdzielić ze sobą
+ jądro jego bazowego systemu, bez znaczenia jaka dystrybucja jest
+ uruchomiona w kontenerze. Procesy przestrzeni użytkownika mogą
+ pochodzić z wielu różnych dystrybucji w przypadku kontenerów.
</p>
<p>
Kontenery są ograniczne za pomocą kilku opcji jądra, przez co one:
</p>
<ul>
- <li>Mają własne groupy <em>cgroup</em></li>
+ <li>Mają własne grupy <em>cgroup</em></li>
<li>Mają własne urządzenia i systemy plików</li>
<li>Nie mogą uzyskać dostępu do jakichkolwiek innych procesów w
w systemie ani prowadzić z nimi interakcji.</li>
poustawiać te wszystkie aspekty ręcznie. Dlatego też korzysta się
z uproszczonych systemów konteneryzacji takich jak
<strong>Docker</strong>. Nie mniej jednak za pomocą takie systemu
- <em>LXC</em> mamy możliwość własnoręcznego skonfigurowania tych
- zagadanień. W tym rozdziale nacisk położono na Docker, ale system
- LXC również po krótce omowiono.
+ LXC mamy możliwość własnoręcznego skonfigurowania tych
+ zagadanień. W tym rozdziale nacisk położono na <em>Docker</em>, ale
+ system LXC również po krótce omowiono.
</p>
<h3 id="16.2.1.dockerandpodman">16.2.1. Docker i Podman</h3>
<p>
- Docker jest jednym z podstawowych narzędzi kontenerowych, jest on
+ <em>Docker</em> jest jednym z podstawowych narzędzi kontenerowych,
+ jest on
bardzo łatwy do instalacji z strony projektu. Wymaga do korzystania
z kontenerów procesu serwera oraz przywilejów superużytkownika aby
uzyskać dostęp do opcji jądra.
</p>
<p>
- Alternatywą dla dockera jest <strong>Podman</strong>. Nie wymaga on
- do swojego działania procesu serwera. Podman może zostać uruchomiony
+ Alternatywą dla <em>Dockera</em> jest <strong>Podman</strong>. Nie
+ wymaga on
+ do swojego działania procesu serwera. <em>Podman</em> może zostać
+ uruchomiony
z uprawnieniami zwykłego użytkownika (ang. <em>rootless</em>),
wówczas stosowane są inne mechanizmy do uzyskania izolacji. Jeśli
- uruchomimy Podman z uprawnieniami administratora to użyje on
- rozwiązań stosowanych przez Docker. Podman jest kompatybilny pod
- względem wiersza polecenia z Dockerem. Oczywiście występują różnice
- w implementacji, szczególnie gdy Podman działa z uprawnieniami
+ uruchomimy <em>Podman</em> z uprawnieniami administratora to użyje on
+ rozwiązań stosowanych przez <em>Docker</em>. <em>Podman</em> jest
+ kompatybilny pod
+ względem wiersza polecenia z <em>Dockerem</em>. Oczywiście występują
+ różnice
+ w implementacji, szczególnie gdy <em>Podman</em> działa z
+ uprawnieniami
zwykłego użytkownika. Jeśli gdzieś zajdzie taka potrzeba rożnice
- między tymi systemami zostaną wyraźnie zaznaczone.
+ między tymi systemami zostaną one wyraźnie zaznaczone.
</p>
<p>
- W tym materiale skupie się na <em>Docker</em>-ze. Podmana z resztą już omawiałem
+ W tym materiale skupie się na <em>Docker</em>-ze. <em>Podman</em>-a z
+ resztą już omawiałem
w tym rozdziale materiału o RHCSA: <a href="https://morketsmerke.github.io/articles/terminallog/RedHat_-_RHCSA.html#23.containers">https://morketsmerke.github.io/articles/terminallog/RedHat_-_RHCSA.html#23.containers</a>
</p>
<h3 id="16.2.2.dockerusage">16.2.2. Użycie Dockera</h3>
Po zapisaniu zmian w pliku <em>Docker</em>-a, wydajemy poniższe
polecenie.
Opcja <code class="code-inline">-t lp_test</code> wskazuje na
- identyfikator obrazu. Później łatwiej będzie go lokalizować,
+ identyfikator obrazu. Później łatwiej będzie go zlokalizować,
ewentualnie wykorzystać do utworzenia nowego kontenera.
</p>
<pre class="code-block">
Successfully tagged lp_test:latest
</pre>
<p>
- Zwróćmy uwagę na informacje zwracane przez Docker podczas przetwarzania
+ Zwróćmy uwagę na informacje zwracane przez <em>Docker</em> podczas
+ przetwarzania
pliku <em>Dockerfile</em>. Na początku pobierany jest oficjalny
obraz kontenera dystrybucji Alpine Linux
(id: <code class="code-inline">05455a08881e</code>) na jego podstawie
Jak możemy wywnioskować po pierwszym wpisie, to coś się działo.
Jednak nie wiele z tego użyliśmy. Jeśli chcelibyśmy uruchomić
kontener w drugim trybie <strong>interaktywnym</strong> to wówczas
- musimy do podpolecenia <code class="code-inline">run</code> opcje
+ musimy do podpolecenia <code class="code-inline">run</code> dodać
+ opcje
<em>-it</em>, czyli <em>-i</em> - praca interaktywna oraz <em>-t</em>
- podłączenien terminala.
</p>
Za tego typu zachowanie odpowiedzialna jest jedna z opcji jądra
wykorzystywana na potrzeby kontenerów - <strong>przestrzenie nazw</strong>
Dzięki tej funkcji proces może utworzy zupełnie nowy zestaw
- identyfikatorów dla siebie oraz swoich procesów potomnych zaczynająć
+ identyfikatorów dla siebie oraz swoich procesów potomnych zaczynając
do PID-u 1. Procesy te będą wówczas miały dostęp tylko do tego
identyfikatora.
</p>
swoje działania przed zapisaniem zmian w górnym katalogu.</li>
</ul>
<p>
- W przypadku Podmana bez uprawnień, wykorzystywany nakładkowy system
- plików w wersji FUSE.
+ W przypadku <em>Podmana</em> bez uprawnień, wykorzystywany nakładkowy
+ system plików w wersji FUSE.
</p>
<h4>Obsługa sieci</h4>
<p>
sieci zewnętrznych (w tym sieci lokalnej) hosta, w tym do Internetu.
</p>
<p>
- Podman bez uprawnień wykorzystuje natomiast interfejsy TAP oraz
- mechanizmy przekazujące w postacji daemon <em>slirp4netns</em>, aby
+ <em>Podman</em> bez uprawnień wykorzystuje natomiast interfejsy TAP
+ oraz
+ mechanizmy przekazujące w postaci daemona <em>slirp4netns</em>, aby
uzyskać dostęp do sieci zewnętrznych. To rozwiązanie ma jeden
minus, kontenery niestety nie mogą łączyć się ze sobą.
</p>
</p>
<h2 id="16.3.venv">16.3. Wirtualizacja oparta na środowisku uruchomieniowym</h2>
<p>
- Inny rodzaj wirtualizacji może bazowac na typie środowiska aplikacji.
+ Inny rodzaj wirtualizacji może bazować na typie środowiska aplikacji.
W tym przypadku nie wykorzystuje się innych mechanik niż izolacja i
to tylko określonej aplikacji. Celem takie działania jest zapewnie
spójności między środowiskiem języka programowania wykorzystywanym
przez ważne kompenenty systemu operacjnego, a zapewnieniem możliwości
uruchomienia żądanej przez nas aplikacji. Głównie ma to zastosowanie
- przy Pythonie, i to jego wykorzystamy do przedstawie tego rodziaju
+ przy Pythonie, i to jego wykorzystamy do przedstawienia tego rodzaju
wirtualizacji.
</p>
<p>
uruchomieniowe dla aplikacji w Pythonie. Możemy je smiało również
wykorzystać do programowania, czy testowania modułów z repozytorium
narzędzia <em>pip</em>. W celu opuszczenia do dyspozycji mamy
- polecenie będą funkcją powłoki - <code class="code-inline">deactivate</code>
+ polecenie będące funkcją powłoki -
+ <code class="code-inline">deactivate</code>
Polecenie to przywrócić zmienne środowiskowe oraz ustawienie powłoki
do stanu sprzed uruchomienia skryptu
<code class="code-inline">deactivate</code>. Na podobnej zasadzie
projects / mmdev.git / commitdiff