Zarządzanie użytkownikami
1. Załóż jednym poleceniem (nie interaktywnie!) użytkownika o nazwie ‘Marian’. Spraw, aby jego główną grupą użytkownika była ‘zarzad‘, a grupy pomocnicze to ‘adm’ oraz ‘audio’. Marian ma mieć powłokę ustawioną na /bin/sh.
groupadd zarzad && useradd -g zarzad -G adm,audio -s /bin/sh Marian
2. Spraw, aby każdy nowo założony użytkownik w systemie miał w swoim katalogu plik ‘regulamin.txt’ z jakimś krótkim tekstem w środku.
echo „Regulamin firmy” >> /etc/skel/regulamin.txt
useradd -m user
3. Zmień użytkownikowi Marian powłokę na /usr/bin/nano (to nie jest poprawny shell! Musisz to jakoś obejść). Gdy Ci się uda, zmień mu powłokę na /bin/bash, aby dało się na tym użytkowniku nadal pracować.
chsh -s /usr/bin/nano Marian
chsh -s /bin/bash Marian
4. Ustaw użytkownikowi ‘Marian’ hasło ‘banany69’, ale w sposób nieinteraktywny, za pomocą jednego polecenia.
usermod -p banany69 Marian
5. Wykonaj polecenie ‘whoami’ jako Marian, ale będąc zalogowanym jako root.
sudo -u Marian whoami
6. Zmień (jednym poleceniem) podstawową grupę użytkownika ‘Marian’ na ‘pracownicy’. Jeśli jest taka potrzeba, to przy okazji utwórz taką grupę.
grep „pracownicy” /etc/group && usermod -g pracownicy Marian || addgroup pracownicy; usermod -g pracownicy Marian
7. Wymuś na użytkowniku ‘Marian’ regularną zmianę hasła co 7 dni (jednym poleceniem).
chage -M 7 Marian
8. Zablokuj konto ‘Marian’ tak, aby nie dało się na niego zalogować (nie chodzi o zmianę hasła, ani usunięcie konta), a później ponownie odblokuj tego użytkownika.
usermod -L Marian
usermod -U Marian
9. Spraw, aby nowo zakładani użytkownicy mieli automatycznie przypisywane numery ID od 8000 w górę.
sed -i 's/UID_MIN 1000/UID_MIN 8000/’ /etc/login.defs;
sed -i 's/GID_MIN 1000/GID_MIN 8000/’ /etc/login.defs
10. Spraw, aby Marian po zalogowaniu się na swoje konto zobaczył aktualny uptime i load na serwerze (zakładamy, że Marian używa basha)
echo „uptime” >> /home/Marian/.bashrc
11. Spraw, aby użytkownik ‘Marian’ mógł uruchomić maksymalnie 5 procesów jednocześnie.
echo „Marian soft nproc 5” >> /etc/security/limits.conf
Zarządzanie plikami
Założenia wstępne: w systemie posiadasz tylko trzech użytkowników:
– Marian – jest w grupie ‘uzytkownicy’
– Ania – jest w grupie ‘uzytkownicy’ oraz ‘kontraktorzy’
– Stefan – jest w grupie ‘praktykanci’
1. Załóż pusty plik o nazwie ‘raport.txt’. Ania i Marian mogą czytać jego zawartość. Marian może także pisać do niego, a Stefan nie ma do niego dostępu.
touch raport.txt
chown Marian:uzytkownicy raport.txt
chmod 640 raport.txt
2. Spraw, aby do pliku ‘logi.txt’ dało się tylko dopisywać nowe dane na końcu i aby mogła robić to tylko Ania z Marianem.
chmod 000 logi.txt
setfacl -m u:Ania:rwx logi.txt
setfacl -m u:Marian:rwx logi.txt
chattr +a logi.txt
3. Plik o nazwie ‘config.yaml’ ma być zdatny do odczytania przez wszystkich użytkowników, ale NIKT nie może go usunąć. Nawet jego właściciel.
chmod a+r config.yaml
chattr +u config.yaml
4. Wszyscy użytkownicy mogą zakładać pliki w katalogu /tmp/dane/, ale pomimo tego, że każdy ma tam dostęp, to tylko właścicielom wolno usuwać swoje pliki i zmieniać ich nazwy (i to nawet gdyby plik miał chmod 777!).
chmod o+t /tmp/dane
5. Spraw, aby pliki “pierwszy.txt” oraz “drugi.txt” miały dokładnie taką samą zawartość, a zmiana tekstu w jednym automatycznie powodowała zmianę tekstu w drugim z plików. Zmiana praw dostępu (chmod) do jednego z plików automatycznie zmienia te same prawa na drugim pliku (widoczne przez ls -l).
ln pierwszy.txt drugi.txt
6. Stwórz plik, który ma dokładnie 100MB. Zrób to jednym poleceniem.
dd if=/dev/zero of=plik bs=1M count=100
truncate -s 100M plik
7. Utwórz plik ‘starocie.txt’ w taki sposób, aby polecenie ‘ls -l’ pokazywało, że został on założony 1 stycznia 1999 roku.
touch -d 1999-01-01 starocie.txt
8. W katalogu masz kilkaset plików z rozszerzeniem TXT. Zmień każdemu z nich rozszerzenie na DOC. Zrób to jednym poleceniem, bez pętli.
rename .txt .doc *.txt
9. Jesteś w katalogu, w którym są tysiące plików. Usuń te, których rozmiar jest większy niż 1MB, a nazwa zaczyna się na literę ‘b’. Zrób to jednym poleceniem.
find . -maxdepth 1 -mindepth 1 -type f -size +1M -name „b*” -delete
10. W katalogu masz tysiące plików. Musisz usunąć wszystkie, które NIE zawierają litery ‘x’ w nazwie. Nie używaj do tego pętli (for/while).
find . -maxdepth 1 -mindepth 1 -type f -not -name '*x*’ -delete
11. W katalogu masz dziesiątki plików. Stwórz paczkę ‘paczka.tgz’ (tar+gzip) zawierającą jedynie pliki większe niż 1MB i do tego mające rozszerzenie txt.
find . -mindepth 1 -maxdepth 1 -type f -size +1M -iname „*.txt” | xargs tar czf paczka.tgz
Serwer Apache
Do testowania serwera webowego przyda Ci się polecenie ‘CURL’ (apt install curl). Chcąc odpytać lokalny serwer o domenę np. mrugalski.pl, zrobisz to w następujący
sposób:
curl -H 'Host: mrugalski.pl’ http://localhost
1. Stwórz dwa hosty wirtualne. Jeden o nazwie “pierwszy.pl”, a drugi o nazwie “drugi.pl”. Pod każdym umieść oddzielny plik index.html tak, aby dało się zorientować, który host został wywołany. Za każdym razem, gdy ktoś odpyta o nieistniejący host (np. ‘trzeci.pl’), otwierać ma się zawartość ‘drugi.pl’.
cd /etc/apache2/sites-available
touch pierwszy.pl.conf drugi.pl.conf
#rm 000-default.conf
update: mv 000-default.conf 000-default.conf.old (dzięki Marcin 😉 )
pierwszy.pl.conf:
<VirtualHost *:80>
ServerName pierwszy.pl
DocumentRoot /var/www/html/pierwszy.pl
</VirtualHost>
drugi.pl.conf:
<VirtualHost _default_:80>
ServerName drugi.pl
DocumentRoot /var/www/html/drugi.pl
</VirtualHost>
mkdir /var/www/html/pierwszy.pl /var/www/html/drugi.pl
echo „pierwszy.pl” > /var/www/html/pierwszy.pl/index.html
echo „drugi.pl” > /var/www/html/drugi.pl/index.html
a2ensite pierwszy.pl
a2ensite drugi.pl
systemctl reload apache2
2. Spraw, aby domyślnym plikiem startowym strony ‘drugi.pl’ był ‘start.html’ zamiast ‘index.html’. Dla wszystkich pozostałych domen plikiem startowym ma być ‘cokolwiek.html’.
/etc/apache2/sites-available/drugi.pl.conf:
<VirtualHost _default_:80>
ServerName drugi.pl
DocumentRoot /var/www/html/drugi.pl
DirectoryIndex start.html
</VirtualHost>
/etc/apache2/mods-available/dir.conf:
<IfModule mod_dir.c>
DirectoryIndex cokolwiek.html index.html index.cgi index.pl index.php index.xhtml index.htm
</IfModule>
3. Spraw, aby otworzenie adresu “drugi.pl/abc” powodowało przekierowanie użytkownika na stronę mikr.us.
/etc/apache2/sites-available/drugi.pl.conf:
<VirtualHost _default_:80>
ServerName drugi.pl
DocumentRoot /var/www/html/drugi.pl
DirectoryIndex start.html
Redirect /abc https://mikr.us
</VirtualHost>
4. Spraw, aby serwer do każdej swojej odpowiedzi doklejał nagłówek ‘X-Test: siema!’.
curl -I 'Host: pierwszy.pl’ http://localhost
a2enmod headers
dodanie do pliku /etc/apache2/apache2.conf
<IfModule headers_module>
Header set X-Test „siema!”
</IfModule>
5.Spraw, aby Twój Apache przedstawiał się jako Nginx w nagłówku ‘server’.
apt install libapache2-mod-security2 -y
dodanie do pliku /etc/apache2/apache2.conf:
<IfModule security2_module>
SecRuleEngine on
ServerTokens Full
SecServerSignature „Nginx”
</IfModule>
6. Zabroń użytkownikom pobierania plików z rozszerzeniem JPG w ramach hosta ‘drugi.pl’ (pozostałe mają działać).
do pliku konfiguracyjnego vhosta należy dodać:
<FilesMatch „\.jpg”>
Order allow,deny
Deny from all
</FilesMatch>
7. Serwer ‘pierwszy.pl’ ma obsługiwać wszystkie możliwe subdomeny w ramach swojej domeny, czyli np: ‘test01.pierwszy.pl’, ‘test02.pierwszy.pl’, czy nawet ‘losowy-ciag-znakow.pierwszy.pl’.
/etc/apache2/sites-available/pierwszy.pl.conf:
<VirtualHost *:80>
ServerName pierwszy.pl
ServerAlias *.pierwszy.pl
DocumentRoot /var/www/html/pierwszy.pl
</VirtualHost>
8. Zabroń ludziom z adresów IP 123.123.*.* wchodzić na stronę ‘drugi.pl’.
dodanie do konfiguracji wirtualnego hosta (drugi.pl.conf) wewnątrz dyrektywy <VirtualHost>
<Directory />
Deny from 123.123.*.*
</Directory>
9. Spraw, aby każde odwołanie do nieistniejącego pliku (error 404) wyświetlało komunikat “Ojeeej… pliku nie ma!”.
echo „Ojeeej… pliku nie ma!” >> /usr/share/apache2/error/404.html
w pliku conf-enabled/localized-error-pages.conf należy odkomentować linię
Alias /error/ „/usr/share/apache2/error/”
oraz odkomentować i zmodyfikować dyrektywę dla błędu 404
ErrorDocument 404 /error/404.html
10. Twój Apache przy domyślnej konfiguracji, prawdopodobnie na starcie uruchamia 5 swoich procesów. Spraw, aby na starcie uruchomił ich 10, ale w razie dużego ruchu nigdy nie uruchamiał więcej niż 20 instancji.
w pliku /etc/apache2/mods-enabled/mpm_event.conf zmieniamy dyrektywę dwie wartości dyrektyw
StartServers 10
MaxRequestWorkers 20
11. Sprawdź, jak długo uruchomiony jest Apache, ale korzystając jedynie z narzędzia CURL. Metoda ta zwróci Ci wiele innych, ciekawych statystyk, ale działa tylko na
Twoim serwerze (nie da się jej użyć ‘z internetu’).
curl -s http://localhost/server-status | grep uptime
Serwer Nginx [RHEL]
Do testowania serwera webowego przyda Ci się polecenie ‘CURL’ (apt install curl). Chcąc odpytać lokalny serwer o domenę np. mrugalski.pl, zrobisz to w następujący
sposób:
curl -H 'Host: mrugalski.pl’ http://localhost
1. Stwórz trzy serwery webowe, obsługujące kolejno domeny ‘pierwszy.pl’, ‘drugi.pl’ oraz ‘trzeci.pl’. Każda z domen ma odpowiadać innym tekstem (aby dało się je rozróżnić), a odpytanie domeny nieistniejącej ma wyświetlać zawartość serwera ‘drugi.pl’
cd /etc/nginx/conf.d/
pierwszy.pl.conf:
server {
listen 80;
server_name pierwszy.pl;
root /var/www/pierwszy.pl;
}
drugi.pl.conf:
server {
listen 80 default_server;
server_name drugi.pl;
root /var/www/drugi.pl;
}
trzeci.pl.conf:
server {
listen 80;
server_name trzeci.pl;
root /var/www/trzeci.pl;
}
cd /var/www
mkdir pierwszy.pl drugi.pl trzeci.pl
echo „pierwszy.pl” >> pierwszy.pl/index.html
echo „drugi.pl” >> drugi.pl/index.html
echo „trzeci.pl” >> trzeci.pl/index.html
2. Twoja instancja Nginx ma uruchamiać domyślnie 8 workerów (domyślnie uruchamia mniej, zazwyczaj tyle, ile masz wątków w procesorze).
W pliku /etc/nginx/nginx.conf należy zmienić wartość dyrektywy:
worker_processes 8;
Domyślna wartość auto ustala na taką ilość ile jest rdzeni
3. Spraw, aby katalog o nazwie ‘dane’ w ramach domeny ‘pierwszy.pl’, jeśli nie zawiera pliku ‘start.html’, był listowany (czyli w przeglądarce wyświetla się spis
znajdujących się w nim plików). Jeśli jednak plik ‘start.html’ istnieje, to ma się wyświetlić jako domyślny.
pierwszy.pl.conf:
server {
listen 80;
server_name pierwszy.pl;
root /var/www/pierwszy.pl;
location /abc {
index start.html;
autoindex on;
}
}
4. Pod adresem ‘drugi.pl/test01’ powinny ładować się pliki z katalogu /var/www/abc, a pod adresem ‘drugi.pl/test02’ pliki z katalogu /var/www/xyz. Dla wszystkich
pozostałych adresów pliki powinny ładować się z katalogu /var/www/domyslne.
Zamiana dyrektywy root w pliku nginx.conf:
root /var/www;
mkdir /var/www/{abc,xyz,domyslne}
echo „xyz” >> /var/www/xyz/index.html
echo „abc” >> /var/www/abc/index.html
echo „domyslne” >> /var/www/domyslne/index.html
drugi.pl.conf:
server {
listen 80 default_server;
server_name drugi.pl;
root /var/www/domyslne;
location /test01 {
alias /var/www/abc;
}
location /test02 {
alias /var/www/xyz;
}
}
5. Spraw, aby wszystkie pliki *.JPG oraz *.PNG podawane z domeny ‘trzeci.pl’, posiadały nagłówek cachujący (Expires: ….) ustawiony na 30 dni od daty wywołania zapytania.
trzeci.pl.conf:
server {
listen 80;
server_name trzeci.pl;
root /var/www/trzeci.pl;
location ~* \.(?:jpg|png)$ {
expires 30d;
}
}
6. Skonfiguruj serwer tak, aby wszystkie adresy zaczynające się od słowa ‘skok’ w domenie ‘drugi.pl’ przekierowywały na stronę mikr.us. Czyli poprawne URLe to np ‘drugi.pl/skokXY’ lub ‘drugi.pl/skokowy’, czy ‘drugi.pl/skok999’
drugi.pl.conf:
server {
listen 80 default_server;
server_name drugi.pl;
root /var/www/drugi.pl;
rewrite ^(/skok.*)$ https://mikr.us last;
}
7. Spraw, aby odwołanie do nieistniejącego pliku (error 404) skutkowało wyświetleniem komunikatu o treści ‘Pliku nie ma!’, a do tego aby strona z błędem miała kod odpowiedzi ‘200 OK’.
dodanie do sekcji http pliku nginx.conf :
error_page 404 =200 „Pliku nie ma!”;
8. Zezwól na wejście na hosta ‘trzeci.pl’ jedynie adresom 1.2.3.4 oraz .9.8.7.6. Wszystkie pozostałe mają otrzymać komunikat “Zakaz wstępu!”.
trzeci.pl.conf:
server {
listen 80;
server_name trzeci.pl;
root /var/www/trzeci.pl;
error_page 403 /403.html;
location / {
allow 1.2.3.4;
allow 9.8.7.6;
deny all;
}
location /403.html {
root /var/www/trzeci.pl;
allow all;
}
}
echo „Zakaz wstępu!” >> /var/www/trzeci.pl/403.html
9. Spraw, aby domena ‘pierwszy.pl’ obsługiwała jedynie zapytania typu GET. Wszystkie pozostałe mają otrzymać komunikat “Błędna metoda!”
echo „Bledna metoda!” > /var/www/pierwszy.pl/403.html
do pliki pierwszy.pl.conf należy dopisac:
error_page 403 /403.html;
location / {
limit_except GET {
deny all;
}
10. Dodaj do wszystkich plików, których nazwa zaczyna się na literę ‘a’, a do tego pochodzą z hosta ‘pierwszy.pl’, nagłówek ‘X-Test: OK’
Do pliku pierwszy.pl.conf należy dopisać:
location ~* a.*$ {
add_header X-Test „OK”;
}
11. Spraw, aby każdemu otwierającemu hosta ‘trzeci.pl’ wyświetlała się zawartość portalu wp.pl. To nie ma być przekierowanie, a bezpośrednie podanie zawartości. Dodatkowo podmień wszystkie wystąpienia słowa ‘wczoraj’ na ‘jutro’.
Do pliku trzeci.pl.conf należy dopisać:
location / {
proxy_set_header Host „wp.pl”;
proxy_set_header X-Forwarder-For $proxy_add_x_forwarded_for;
proxy_pass https://wp.pl;
sub_filter „wczoraj” „jutro”;
}
Automatyzacja Ansible
W zadaniach zakładam, że Twój plik “inventory” wygląda jak poniżej, a wszystkie serwery działają pod kontrolą systemu Ubuntu.
[web]
web01.mikr.us
web02.mikr.us
web03.mikr.us
[other]
mysql.mikr.us
psql.mikr,us
1. Wykonaj polecenie ‘uptime’ na wszystkich serwerach z grupy WEB z wyjątkiem web03. Zrób to jednym poleceniem, bez tworzenia playbooka
ansible web -m shell -a „uptime” –limit 'web:!web03′
2. Na serwerze ‘mysql’ odblokuj na firewallu (ufw) ruch na port 3306 ze wszystkich serwerów z grupy WEB
3. Załóż katalog “klucze” i wrzuć do niego trzy publiczne klucze SSH (każdy w osobnym pliku). Każdy z nich dodaj do authorized_keys na wszystkich serwerach z inventory
cat group_vars/all :
ssh_user:
– root
– ubuntu
– stefan
4. Na każdym serwerze zainstaluj fail2ban. Skonfiguruj go tak, aby nie banował żadnego serwerów z inventory, czyli skonfiguruj odpowiednio linijkę ‘ignoreip’ w pliku jail.conf. Po zmianach przeładuj fail2ban, ale spraw aby reload nie oznaczał statusu serwera jako ‘changed’
5. Przygotuj playbooka gotowego do obsłużenia zarówno Ubuntu jak i systemów z rodziny RedHat. Zainstaluj na każdym serwerze paczkę ‘vim’. Dla serwerów z rodziny Debiana użyj ‘apt’, a dla tych z rodziny RedHata użyj ‘yum’
6. Załóż na każdym serwerze plik /tmp/host_XYZ, gdzie XYZ to nazwa domenowa danego serwera. Jako zawartość pliku wstaw tekst ‘OK’. Jeśli w katalogu /tmp/ istnieją inne pliki z prefiksem ‘host_’, usuń je.
7. Na każdym z hostów postaw kontener dockera z Nginx, wystawiając jego port 80 na zewnątrz.
ansible-galaxy install geerlingguy.docker -p /etc/ansible/roles/
cat group_vars/web :
docker_edition: 'ce’
docker_packages:
– „docker-{{ docker_edition }}”
– „docker-{{ docker_edition }}-cli”
– „docker-{{ docker_edition }}-rootless-extras”
docker_packages_state: present
docker_install_compose: true
8. Upewnij się, że na każdym serwerze istnieje grupa ‘wheel’ (jeśli jej nie ma, to dodaj) i że należy do niej użytkownik ‘stefan’ (jeśli go nie ma, to załóż). Spraw, aby użytkownicy z grupę wheel mieli prawo używania polecenia ‘su’
9. Napisz playbooka, który postawi WordPressa na aktualnym serwerze dla domeny testuje.pl
files/testuje.pl.conf :
<VirtualHost *:80>
DocumentRoot /var/www/html/wordpress
ServerName testuje.pl
</VirtualHost>
10. Spróbuj przebudować playbooka z zadania numer 9 w taki sposób, aby nie wykorzystywać żadnego wbudowanego modułu Ansible. Wykorzystaj gotowe ‘role’ do postawienia wcześniej wspomnianej konfiguracji.
ansible-galaxy install inmotionhosting.apache -p /etc/ansible/roles
ansible-galaxy install inmotionhosting.mysql -p /etc/ansible/roles
ansible-galaxy install inmotionhosting.php_fpm -p /etc/ansible/roles
ansible-galaxy install inmotionhosting.wordpress -p /etc/ansible/roles
groups_var/web:
site_domain: testuje.pl
site_email: „biuro@wojst.pl”
site_user: „wojtek”
site_pass: „password”
install_wordpress: true
system_user: „wordpress”
php_fpm_daemon: „php-fpm”
W pliku /etc/ansible/roles/inmotionhosting.mysql/vars/debian.yml musiałem wykomentować pakiet, ponieważ zwracało błąd podczas instalacji:
# – python-pymysql
W pliku /etc/ansible/roles/inmotionhosting.php_fpm/tasks/facts.yml musiałem wykomentować task: Set installed PHP version
W pliku /etc/ansible/roles/inmotionhosting.wordpress/tasks/main.yml musiałem zmienić, ponieważ próbowało dodawać usera do grupy nobody, która nie istnieje:
groups: „{{ system_user }},www-data”
11. Przygotuj playbooka do zabezpieczenia serwera SSH. Wyłącz możliwość bezpośredniego logowania się na konto ‘root’. Zmień domyślny numer portu usługi z 22 na 10022. Skonfiguruj firewalla (UFW) w taki sposób, aby akceptował połączenia na nowy numer portu i odrzucał na stary. Spraw, aby logowanie było możliwe jedynie za pomocą klucza (wyłącz dostęp po haśle). Postaraj się wszystkie zmiany w pliku konfiguracyjnym SSH wprowadzić w jednej pętli (bez wywoływania tylu pasków ile zmian).
Kontenery Dockera
1. Uruchom kontener z serwerem webowym Nginx w taki sposób, aby domyślna strona startowa podawana była z katalogu /tmp/strona/ (wrzuć tam plik index.html z dowolnym tekstem). Spraw także, aby kontener został automatycznie usunięty po jego wyłączeniu i aby nasłuchiwał na porcie 80 i przyznaj mu maksymalnie 256MB pamięci. Wykonaj to zadanie z linii poleceń, korzystając z tylko jednego polecenia startowego.
docker image pull nginx:latest
docker container run -d –name nginx –rm -m 256m -p 80:80 -v /tmp/strona:/usr/share/nginx/html:ro nginx
2. Wykonaj backup oryginalnego obrazu kontenera z poprzedniego zadanie w taki sposób, aby uzyskać plik TGZ, a następnie postaraj się odtworzyć ten backup.
docker save nginx:latest | gzip -c > nginx.tgz
gunzip -c nginx.tgz | docker load
3. Wykonaj zadanie numer 1 z użyciem pliku Dockerfile.
FROM nginx:latest
LABEL maintainer=”WOJST”
EXPOSE 80
4. Korzystając z Docker-Compose postaw działającego WordPressa, składającego się z serwera Apache z obsługą PHP (znajdź gotowy obraz) i serwera MySQL (lub MariaDB jeśli lubisz). Zadbaj, aby w przypadku restartu któregoś z serwerów nie utracić danych należących do WordPressa.
mkdir app mysql
wget https://wordpress.org/latest.zip && unzip -d app/ latest.zip
docker_compose.yaml:
version: '3.1′
services:
db:
image: mariadb
restart: always
volumes:
– ./mysql:/var/lib/mysql
environment:
MYSQL_ROOT_PASSWORD: pass
MYSQL_USER: admin
MYSQL_PASSWORD: test
MYSQL_DATABASE: database
web:
image: romeoz/docker-apache-php
ports:
– „80:80”
links:
– db
volumes:
– ./app/wordpress:/var/www/app/
5. Sprawdź jakie pliki zostały zmienione w kontenerze z MySQL od chwili jego uruchomienia.
docker diff mysql
6. Stwórz obraz kontenera uruchamiający skompilowaną aplikację “Hello World” napisaną w GO na kontenerze bazującym na dystrybucji Alpine, na której nie ma kompilatora wspomnianego języka. Postaraj się, aby docelowy obraz miał możliwie niewielki rozmiar. Idealnie byłoby, aby poza czystą dystrybucją znalazła się tam tylko skompilowana aplikacja.
hello.go:
package main
import „fmt”
func main() {
fmt.Println(„hello world”)
}
Dockerfile:
FROM golang:latest AS builder
WORKDIR /
COPY hello.go /
RUN go build /hello.go
FROM alpine:latest
COPY –from=builder /hello /
ENTRYPOINT [„/hello”]
docker build -t go-hello .
docker run go-hello
7. Postaw kontener z Apache2 oraz jeden z Nginx. Następnie obok nich uruchom kontener z ‘Nginx Proxy Manager’. Wykorzystując swoją prawdziwą domenę spraw, aby pod subdomeną ‘apache’ ładowała się zawartość pierwszego kontenera, a pod subdomeną ‘nginx’ tego drugiego. Zadbaj, aby każda ze stron działała po HTTPS. Spraw, aby oba serwery webowe mogły się komunikować po prywatnej sieci z Proxy Managerem.
docker network create apache
docker network create nginx
docker network create -d bridge public
docker run -d –hostname=apache –net=apache –name apache httpd
docker run -d –hostname=nginx –net=nginx –name nginx nginx
docker-compose.yml:
version: '3.1′
services:
app:
image: 'jc21/nginx-proxy-manager:latest’
restart: always
networks:
– apache
– nginx
– public
ports:
– „80:80”
– „443:443”
– „81:81”
environment:
DISABLE_IPV6: 'true’
volumes:
– ./data:/data
– ./letsencrypt:/etc/letsencrypt
networks:
apache:
nginx:
public:
external: true
8. Wrzuć do działającego kontenera (może to być np. uruchomiony Nginx) plik ‘test.txt’ o dowolnej zawartości, a następnie uruchom powłokę bash/sh/ash na tym samym kontenerze i za pomocą polecenia ‘cat’ podglądnij zawartość wrzuconego pliku.
docker container run -itd –name nginx nginx
echo „testowy plik” >> ~/test.txt
docker cp ~/test.txt nginx:/tmp
docker exec -it nginx bash
cat /tmp/test.txt
9. Przygotuj własny obraz kontenera z Apache, obsługującym język PHP. Możesz wykorzystać dowolny obraz czystego systemu jako bazowy (najlepiej Alpine, ale równie dobrze może to być Debian, czy Ubuntu jeśli nie zależy Ci na optymalizacji rozmiaru). Następnie wyślij ten obraz na DockerHuba.
Dockerfile:
FROM ubuntu:latest
LABEL mainteiner=”WOJST”
ENV TZ=Europe/Warsaw
RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone
RUN apt update && apt install -y apache2 php8.1 libapache2-mod-php8.1
EXPOSE 80
CMD [„/usr/sbin/apache2ctl”, „-D”, „FOREGROUND”]
docker container run -itd -p 80:80 –name ubuntu_apache_php -v ./app:/var/www/html ubuntu-wojst
Utworzenie repo na hub.docker.com
docker login
docker tag ubuntu-wojst:latest wojstit/ubuntu-wojst:1.0
docker push wojstit/ubuntu-wojst:1.0
10. Poznaj podstawy korzystania z API Dockera. Używając narzędzia NetCat (apt install nc) pobierz listę obrazów dostępnych na Twoim serwerze. Zwróć ją w formacie JSON.
curl –unix-socket /var/run/docker.sock http://localhost/images/json | jq
11. Przygotuj sobie dwie wirtualne maszyny (VPSy) z zainstalowanym dockerem. Na pierwszym z nich uruchom konfigurację z zadania numer 4. Następnie spróbuj tę konfigurację przenieść na drugi serwer metodą zatrzymania kontenerów, synchronizacji plików i podniesienia kontenerów na drugim serwerze. Ważne jest, aby nie utracić żadnych danych należących do WordPressa (pliki + DB).
Na pierwszym hoście:
docker-compose stop
docker export -o web.tar 4_web_1
docker export -o db.tar 4_db_1
scp -r 4/ root@192.168.1.131:/root
(w katalogu 4 są volumeny, które były podmontowane oraz tary utworzone przed chwilą)
Na drugim hoście, po przekopiowaniu:
docker import web.tar 4_web_1:latest
docker import db.tar 4_db_1:latest
docker compose up -d