Kubernetes K3s #1

Cześć! Po wielu (nieudanych) próbach postawienia klastra Dockerowego na Mikrusie, postanowiłem dzisiaj postawić klaster Kubernetesa 🙂

Dlaczego K3s?

Odpowiedź jest prosta, tak samo jak złożoność K3s. K3s jest bardzo prosty w instalacji i jest nawet skrypt do jego uruchomienia na serwerach Mikrusachce_k3s.sh – autorstwa Macieja Lopera, wraz z moimi poprawkami i poprawką Grzegorza „es1o” Eliszewskiego, która dodawała do skryptu dual-stack (IPv4 + IPv6).
Pewna osoba poleciła mi pobawić się takim czymś jak minikube ale dla dobra Was wszystkich, moi drodzy czytelnicy, nie próbujcie tego tykać, jeżeli nie chcecie stracić ani chwili cennego czasu na jakiekolwiek testy.

Instalacja K3s

Tak jak już napisałem, instalacja K3s jest prosta, gdyż na serwerach Mikrusa wystarczy uruchomić skrypt chce_k3s.sh, lecz ja chciałbym Was przeprowadzić krok po kroku abyście mogli się nauczyć stawiania K3s w nowszych i starszych wersjach 🙂

Pobieramy sobie na początek binarkę K3s w wersji w której działa dual-stack

wget -O /usr/local/bin/k3s https://github.com/k3s-io/k3s/releases/download/v1.27.6%2Bk3s1/k3s

Następnie nadajemy jej uprawnienia do uruchamiania

chmod +x /usr/local/bin/k3s

oraz tworzymy konfigurację pod systemd

cat <<EOF >"/etc/systemd/system/k3s.service"
[Unit]
Description=Lightweight Kubernetes
Documentation=https://k3s.io
Wants=network-online.target
After=network-online.target

[Install]
WantedBy=multi-user.target

[Service]
Type=notify
EnvironmentFile=-/etc/default/%N
EnvironmentFile=-/etc/sysconfig/%N
EnvironmentFile=-/etc/systemd/system/k3s.service.env
KillMode=process
Delegate=yes
# Having non-zero Limit*s causes performance problems due to accounting overhead
# in the kernel. We recommend using cgroups to do container-local accounting.
LimitNOFILE=1048576
LimitNPROC=infinity
LimitCORE=infinity
TasksMax=infinity
TimeoutStartSec=0
Restart=always
RestartSec=5s
ExecStartPre=/bin/sh -xc '! /usr/bin/systemctl is-enabled --quiet nm-cloud-setup.service'
ExecStartPre=-/sbin/modprobe br_netfilter
ExecStartPre=-/sbin/modprobe overlay
ExecStart=/usr/local/bin/k3s \\
    server \\
    --cluster-cidr=10.42.0.0/16,2001:cafe:42:0::/56 \\
    --service-cidr=10.43.0.0/16,2001:cafe:42:1::/112 \\
    --kubelet-arg=feature-gates=KubeletInUserNamespace=true \\
    --kube-controller-manager-arg=feature-gates=KubeletInUserNamespace=true \\
    --kube-apiserver-arg=feature-gates=KubeletInUserNamespace=true \\
    --cluster-init
EOF

Poniższe linie włączają dual-stack, więc jeśli ktoś by miał problem z nowszą wersję to prawdopodobnie przez te linie:

    --cluster-cidr=10.42.0.0/16,2001:cafe:42:0::/56 \\
    --service-cidr=10.43.0.0/16,2001:cafe:42:1::/112 \\


W tym momencie wystarczy wykonać polenie włączenia serwisu k3s w systemie i uruchomienia jej

systemctl enable --now k3s.service

K3s na serwerach z pełną wirtualizacją, bądź na serwerach fizycznych (czyli nie na LXC – jak w przypadku Mikrusa), wymaga jeszcze dodania dodatkowej linijki w pliku /etc/default/grub pod linią GRUB_CMDLINE_LINUX:

GRUB_CMDLINE_LINUX="cgroup_enable=memory cgroup_memory=1 swapaccount=1 systemd.unified_cgroup_hierarchy=0"

oraz zrobienia update’u gruba i zrestartowania systemu:

update-grub
reboot now

Od tego momentu wszystkie rzeczy wykonujemy lokalnie na naszym komputerze.


Wgrywanie kubectl

Instrukcje instalacji można znaleźć pod tym linkiem: https://kubernetes.io/docs/tasks/tools/#kubectl

Wgrywanie Helma

Aby wgrać Helma na nasz komputer wystarczy wykonać jedno polecenie:

MacOS:

brew install helm

Linux/Unix:

curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash

Windows (wystarczy pobrać, rozpakować i pracować na binarce helm.exe):

https://get.helm.sh/helm-v3.13.2-windows-amd64.zip

Teraz możemy sobie sprawdzić czy działa nam helm poprzez przykładowe polecenie, które powinno wyprintować nam pomoc helma:

helm help

Zgrywanie konfiguracji kubeconfig

Aby zgrać sobie konfigurację kubeconfig należy wejść na serwer i zgrać sobie plik /etc/rancher/k3s/k3s.yaml
Mając już ten plik wystarczy w systemie MacOS/Linux/Unix (niestety ale nie mam zielonego pojęcia jak zrobić to w Windowsie) ustawić dwie zmienne środowiskowe które definiują ścieżkę do pliku k3s.yaml:

export KUBE_CONFIG_PATH=/sciezka/do/pliku/k3s.yaml
export KUBECONFIG=/sciezka/do/pliku/k3s.yaml

Po wykonaniu tych dwóch poleceń należy jeszcze ustawić port forwarding.
Tak na marginesie to do pracy na Kubernetesie polecam takie narzędzie jak OpenLens. Jest to graficzna nakładka na kubectl.

SSH port forwarding

Jeżeli będziemy chcieli połączyć się z naszym Kubernetesem za pomocą kubectl to polecam zrobić sobie port forwarding, gdyż jeżeli nie posiadamy adresu IPv6 to dostanie się po IPv4 jest niemożliwe – no chyba, że jest postawiony serwer VPN który łączy się z Mikrusem, to wówczas można dostać się po adresacji VPN.
Sposoby na utworzenie przekierowania portu:

Linux/Unix/MacOS

ssh uzytkownik@adres_ip_mikrusa -p port_mikrusa -L 6443:localhost:6443

Windows

Dla systemu Windows pobieramy program PuTTy. Pobieramy ten program i instalujemy i uruchamiamy albo uruchamiamy (w zależności od pobranej wersji).

Otwieramy program PuTTy i podajemy dane do serwera SSH, a następnie w kategoriach przechodzimy do SSH -> Tunnels

Teraz podajemy dane dla tunelu i klikamy Add

Od tej pory będziemy mieli dostępny port serwera 6443 u nas lokalnie na komputerze, a więc będziemy mogli wykonywać operacje na Kubernetesie.

No chyba, że posiada ktoś adres IPv6 w swojej sieci domowej to niepotrzebne jest robienie przekierowania portu, gdyż port jest wystawiony na świat po adresacji IPv6, choć zawsze można to zmienić 🙂

Instalacja Ingressa NGINX

Aby zainstalować ingressa ważne jest aby wyłączyć i usunąć traefika z Kubernetesa.

kubectl -n kube-system scale deploy traefik --replicas=0
kubectl -n kube-system delete deploy traefik
kubectl -n kube-system delete svc traefik
kubectl -n kube-system delete svc traefik-dashboard

Ostatnie polecenie może zakończyć się błędem z powodu braku traefik-dashboard. Tak czy inaczej, wszystko jest okej 🙂

Na początek dodajemy repozytorium ingress-nginxa do naszego helma:

helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx

Aktualizujemy repozytorium:

helm repo update

Tworzymy namespace dla ingressa:

kubectl create ns ingress-nginx

Tworzymy plik ingress-values.yml wraz z poniższą zawartością

controller:
  service:
    enabled: true
    ipFamilies:
      - IPv6

Następnie możemy wgrać ingressa na naszego Kubernetesa:

helm upgrade --install nginx-ingress ingress-nginx/ingress-nginx --namespace ingress-nginx -f ingress-values.yml

Z wgrywaniem ingressa mogą być problemy, ale po dłuższym odczekaniu ingress zostanie zainstalowany:

Deployowanie pierwszej aplikacji

Teraz aby sprawdzić czy ingress działa tworzymy sobie pliczek first-deployment.yaml z poniższą zawartością

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80

---

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  type: ClusterIP

---

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: nginx-ingress
spec:
  ingressClassName: nginx
  rules:
  - host: twojadomena.tld # tu wpisz swoją domenę
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: nginx-service
            port:
              number: 80

gdzie w miejsce twojadomena.tld podstaw swoją domenę/subdomenę, najlepiej skierowaną przez Cloudflare’a, bądź dodaną poprzez Subdomeny w panelu użytkownika.

Teraz możemy zrobić deploy aplikacji i zobaczyć czy usługa działa:

Jak widzicie, ingress działa poprawnie 🙂

O to koniec części pierwszej związanej ze stawianiem klastra Kubernetesowego. W następnej notce będą przedstawione sposoby na dodawanie node’ów do klastra Kubernetesowego 🙂

Trochę o dockerze #1

Cześć! Wreszcie po długich przemyśleniach postanowiłem opowiedzieć Wam trochę o technologii konteneryzacji znanej też jako „Docker”.

Dlaczego warto używać dockera?

Na wstępie zacznijmy sobie od zrozumienia czym jest konteneryzacja.

Konteneryzacja to metoda umożliwiająca łatwiejsze zarządzanie aplikacjami i ich zależnościami w środowisku deweloperskim.

Aby zobrazować to w prosty sposób, możemy sobie wyobrazić, że aplikacja to paczka prezentów, a kontener to pudełko na te prezenty. Kontenerizacja pozwala na zapakowanie aplikacji w takie pudełko razem z jej zależnościami (czyli innymi prezentami), które są potrzebne do jej działania.

Docker zaś to narzędzie, które umożliwia izolowanie aplikacji w kontenerach, co sprawia że nie ma żadnej potrzeby instalowania aplikacji lokalnie, a także pozwala uniknąć problemów z zależnościami, gdyby na przykład dwie aplikacje potrzebowały różnych wersji bibliotek. Największymi plusami stosowania konteneryzacji jest to, że to użytkownik decyduje o wersji danej aplikacji i nie musi być ona zawsze najnowsza (jak to jest w repozytorium systemu), oraz to, że użytkownik zostawia zawsze porządek na swoim głównym serwerze produkcyjnym, gdyż chcąc usunąć daną aplikację kasuje kontener i po problemie.

Jak uruchomić kontener w Dockerze?

Aby uruchomić kontener w Dockerze powinniśmy:

  • ustalić jaką aplikację chcemy uruchomić
  • czy chcemy wystawiać aplikację na zewnątrz
  • czy kontener ma sobie działać w tle

Takim podstawowym poleceniem aby uruchomić kontener z aplikacją NGINX jest:

docker run -d nginx

Czym różni się uruchomienie Dockera z parametrem -d, a uruchomienie go bez tego parametru?

Uruchomienie kontenera z parametrem -d oznacza, że kontener będzie działał w tle (w trybie „detach”), a proces kontenera będzie uruchomiony w tle i nie będzie wyświetlał się na standardowym wyjściu, takim jak konsola lub terminal.

Uruchomienie kontenera bez parametru -d spowoduje, że kontener będzie działał w trybie interaktywnym i będzie wyświetlał logi w terminalu, w którym został uruchomiony. Uruchomienie kontenera bez parametru -d jest używane do debugowania i testowania kontenerów, a także do interaktywnego dostępu do procesu kontenera.

W jaki sposób można ustawić nazwę dla kontenera?

W dockerze aby ustawić nazwę dla kontenera wykorzystuje się parametr --name lub w jego krótszej wersji -n. W Docker Compose domyślnie nazwa bloku kontenera to jego nazwa, na przykład:

services:
    nginx: # ta nazwa bloku kontenera domyślnie będzie także nazwą kontenera
        container_name: nginx # można jeszcze podać nazwę kontenera, ale nie jest to niezbędne
        image: nginx

Dobra, a co jeżeli chcę dodać do jakiegoś obrazu kilka rzeczy bo mi ich w nim brakuje?

Tu z pomocą przychodzi Docker Build. Pozwala on zbudować nowy obraz dla kontenera w oparciu o plik Dockerfile i zamieszczone tam taski (zadania). Przykładem pliku dockerfile, który buduje mi serwer SSH z kilkoma narzędziami do wykorzystania w aplikacji n8n, jest poniższy kod:

FROM ubuntu:20.04
RUN apt update && apt install openssh-server sudo nmap telnet mariadb-client net-tools -y
RUN useradd -rm -d /home/ubuntu -s /bin/bash -g root -G sudo -u 1000 ubuntu
RUN echo 'ubuntu:ubuntu' | chpasswd
RUN service ssh start
EXPOSE 22
CMD ["/usr/sbin/sshd","-D"]

gdzie:

  • FROM – definiuje wersję obrazu na bazie którego ma powstać nowy obraz
  • RUN – definiuje polecenie, które ma zostać wykonane podczas budowania kontenera
  • EXPOSE – definiuje port bądź porty, które są informacją dla użytkownika jakie porty będą nasłuchiwane gdy uruchomimy ten obraz w kontenerze
  • CMD – definiuje polecenie, które ma zostać uruchomione za każdym startem kontenera

Jak utworzyć kontener ze zmodyfikowanym obrazem?

W dokerze aby zbudować obraz należy wydać polecenie docker build -t nazwa_obrazu /ścieżka/do/pliku/Dockerfile, gdzie gdyby nie została podana ścieżka do pliku Dockerfile to wówczas docker by szukał pliku o nazwie Dockerfile w bieżącym katalogu.

Następnie aby uruchomić kontener ze zbudowanego obrazu należy wydać polecenie docker run -d nazwa_obrazu.

W Docker Compose wystarczy dodać poniższy kod do docker-compose.yml:

services:
    ssh_server:
        build:
            context: .
            dockerfile: ssh.dockerfile

gdzie

  • context – docker będzie szukał pliku w katalogu w którym znajduje się plik docker-compose.yml (domyślnie)
  • dockerfile – nazwa pliku dockerfile na podstawie którego ma zostać zbudowany nowy obraz (domyślna nazwa pliku: Dockerfile)

W jaki sposób mógłbym wystawić swoją aplikację na zewnątrz?

Jasne, można to zrobić 🙂 W dockerze można wykorzystać opcję –publish albo w skrócie -p co pozwoli wystawić port aplikacji na zewnątrz np.

docker run -d --name my_nginx -p '80:80' -p '443:443' -v /var/www/html:/var/www/html nginx

albo w Docker Compose:

version: '3'
services:
    my_nginx:
        image: nginx
        restart: always
        volumes:
            - '/var/www/html:/var/www/html'
        ports:
            - '80:80'
            - '443:443'

Jak wygląda zmiana wersji aplikacji w dockerze?

Odpalając kontenery za pomocą polecenie docker run należy:
1. Odszukać kontenery poleceniem docker ps
2. Zatrzymać kontenery poleceniem docker stop <nazwa_kontenera>
3. Skasować kontenery poleceniem docker rm <nazwa_kontenera>
4. Utworzyć kontenery na nowo poleceniem docker run -d ...... z nowszą wersją obrazu.

Jak wygląda zmiana wersji aplikacji w Docker Compose?

Odpalając kontenery za pomocą docker compose należy:
1. Otworzyć plik docker-compose.yml
2. Zmienić wersję obrazu w kontenerach
3. Wykonać polecenie docker-compose up -d

Czy możesz opowiedzieć czym są te volumeny?

Są trzy typy volumenów:

  1. Bind mount
  2. Volume
  3. Tmpfs

Bind mount umożliwia podmontowanie folderu z hosta bezpośrednio do kontenera. Zmiany dokonywane wewnątrz kontenera będą widoczne na hostingu i odwrotnie.

Wolumin to specjalny typ katalogu, który jest zarządzany przez Docker. Wolumin może być współdzielony przez wiele kontenerów, co ułatwia udostępnianie danych pomiędzy aplikacjami.

Tmpfs to rodzaj woluminu, który przechowuje pliki tymczasowe w pamięci RAM. Po wyłączeniu kontenera pliki te zostaną skasowane.

Przykłady:

1. Bind mount:

services:
    nginx:
        image: nginx
        volumes:
            - /var/www/html:/var/www/html

Katalog /var/www/html na głównej maszynie jest odzwierciedleniem katalogu /var/www/html w kontenerze.

2. Volume:

services:
    nginx:
        image: nginx
        volumes:
            - nginx_files:/var/www/html
    tools:
        build:
            context: .
            dockerfile: tools.dockerfile
        volumes:
            - nginx_files:/var/www/html
volumes:
    nginx_files:

Dostęp do tych samych plików mają oba kontenery.

3. Tmpfs

services:
    nginx:
        image: nginx
        volumes:
            - type: tmpfs
              target: /var/cache/nginx

Katalog /var/cache/nginx w kontenerze jest wrzucony do pamięci ram, więc dane tam będą zapisywane i odczytywane znacznie szybciej niż na dysku. Przydatne jest to jeżeli chcemy przyspieszyć działanie serwera WWW. Gdy kontener zostanie wyłączony to dane te zostaną usunięte.

Jeżeli nie zostaną utworzone żadne volumeny to wówczas gdy kontener zostanie skasowany to wszelkie dane na tym kontenerze zostaną skasowane wraz z nim!

Czy da się połączyć kontenery w jedną sieć?

Tak. Domyślnie wszystkie nowo utworzone kontenery znajdują się w podsieci 172.17.0.0/16. Docker jednak pozwala utworzyć nowe podsieci dla kontenerów, gdzie to użytkownik decyduje o tym, który kontener będzie znajdował się w danej sieci. Jest to bardzo pomocne gdy mamy chęć odseparować od siebie kontenery bądź konkretne aplikacje np. jeżeli są dwie bazy danych do dwóch różnych aplikacji i jedna aplikacja ma być w jednej sieci z jedną bazą, a druga baza ma być w drugiej sieci z drugą aplikacją, dzięki czemu obie aplikacje nie zobaczą się wzajemnie.

Przykładem w docker-compose.yml utworzenia nowej sieci dla aplikacji jest:

version: '3'
networks:
  example_network:
    driver: bridge
    ipam:
      config:
        - subnet: 172.20.0.0/16
          gateway: 172.20.0.1

services:
    app:
        build:
            context: .
            dockerfile: app.dockerfile
        restart: always
        volumes:
            - '/var/www/app:/var/www/app'
        networks:
          example_network:
            ipv4_address: 172.20.0.2
    redis:
        image: redis:alpine
        restart: always
        networks:
          example_network:
            ipv4_address: 172.20.0.3

Opis sekcji networks:

networks:
  example_network:
    driver: bridge
    ipam:
      config:
        - subnet: 172.20.0.0/16
          gateway: 172.20.0.1

  • example_network – nazwa sieci, którą definiujemy.
  • driver: bridge – określa typ sieci, w tym przypadku jest to sieć typu bridge, czyli domyślny typ sieci w Dockerze. Bridge to po prostu sieć wewnętrzna, która pozwala na komunikację między kontenerami.
  • ipam – definiuje, jakie adresy IP będą przydzielane kontenerom w tej sieci.
  • config – definiuje konfigurację sieci.
  • subnet – określa pulę adresów IP, jakie będą dostępne w tej sieci.
  • gateway – adres IP, który będzie bramą domyślną dla kontenerów w tej sieci.
        networks:
          example_network:
            ipv4_address: 172.20.0.3

Kontener będzie podłączony do sieci example_network i otrzyma stały adres IP 172.20.0.3

Przykładowy plik docker-compose.yml wraz z opisem:

version: '3' # korzystaj z trzeciej wersji Docker Compose
services: # serwisy
    n8n: # nazwa serwisu: n8n
        image: n8nio/n8n:0.226.2 # obraz to n8n w wersji 0.226.2
        restart: unless-stopped # w razie awarii restartuj tak długo dopóki nie zostanie zatrzymany
        environment: # zmienne środowiskowe
            - N8N_BASIC_AUTH_ACTIVE=true
            - N8N_BASIC_AUTH_USER=admin
            - N8N_BASIC_AUTH_PASSWORD=super_tajne_haslo
            - TZ="Europe/Warsaw"
        volumes: # wolumeny
            - /var/run/docker.sock:/var/run/docker.sock # plik /var/run/docker.sock ma odpowiadać plikowi /var/run/docker.sock w kontenerze
            - '~/.n8n:/home/node/.n8n' # katalog ~/.n8n ma odpowiadać katalogi /home/node/.n8n w kontenerze
        ports: # porty
            - '5678:5678' # na głównej maszynie port 5678 ma kierować do portu 5678 w kontenerze

Na tą chwilę to tyle z podstawowych informacji. Mam nadzieję, że choć trochę przybliżyłem Wam temat tak fajnego narzędzia jak Docker Compose. W następnej notce pokażę Wam jak zrobić deploy niektórych aplikacji (w tym WordPressa) korzystając z Docker Compose 🙂

Dzięki za uwagę,
Ferexio

PS. Czy zauważyłeś że u mnie w plikach YAML każde następne wcięcie to +4 spacje? 🙂

O Miami Vice w Vice City

Poniższy tekst został napisany przez: Jakub Robert Marszałek

Po maratonie Miami Vice naszła mnie ochota na wychwycenie możliwie dużej ilości nawiązań do serialu w Vice City oraz Vice City Stories. Poniżej trochę oczywistości, ale także mniej znanych easter eggów. Trafi się też kilka lekkich spoilerów, więc jeśli ktoś zamierza zapoznać się z tym klasykiem, to czyta na własną rękę.

1. Lance Vance, czyli Rico Tubbs

Jak pewnie większość z was wie, głos Lance’owi podkładał aktor Philip Michael Thomas, który w latach 80-tych wcielał się w rolę Rico Tubbsa – policyjnego partnera głównego bohatera Miami Vice, Jamesa „Sonny’ego” Crocketta.
Na tym jednak nie koniec. Vance’m i Tubbsem kierują bardzo podobne motywacje: obydwoje stracili brata podczas transakcji narkotykowej i szukają zemsty na sprawcach tych wydarzeń.
Ponadto ubrania Vance’a z Vice City Stories mogą nasuwać skojarzenia ze stylem serialowego gliniarza.

2. Muzyka

W zasadzie banalnie prosty temat. Zarówno Vice City, jak i Vice City Stories, są wręcz przeładowane hitami lat 80-tych, w tym piosenkami wykorzystanymi w Miami Vice (In The Air Tonight od Phila Collinsa, I Want To Know What Love Is autorstwa Foreigner itp.). Wśród utworów znajdujących się w grach natrafić możemy między innymi na Crockett’s Theme autorstwa Jana Hammera – słynny motyw wielokrotnie pojawiający się w serialu.

Oficjalny soundtrack gry wydany na płytach CD zawiera także utwór Glenna Freya, Smuggler’s Blues. Piosenka ta została wykorzystana w pierwszym sezonie Miami Vice, w odcinku pod tym samym tytułem. Dlaczego ostatecznie nie trafiła do samej gry? Trudno powiedzieć, jednakże jest to niewątpliwie spora strata, gdyż utwór wręcz idealnie pasuje do klimatu Vice City.

3. Bryan Forbes

Nieco zapomniana postać z Vice City Stories. Forbes to agent DEA (wydział od narkotyków), którego ewidentnie wzorowano na serialowym Sonnym. Biały garnitur? Zgadza się. Pastelowa koszula? Jest. Ferrari Day…Stinger? Jest.

4. Ferrari Daytona/Stinger oraz Ferrari Testarossa/Cheetah

Jak już wspomniałem o samochodzie Forbesa, to należy trochę podrążyć temat. W Miami Vice w oczy rzucają się dwa samochody: Ferrari Daytona Spyder (sezony 1-3) oraz Ferrari Testarossa (sezony 3-5). Auta te znajdziemy w grach, rzecz jasna pod innymi nazwami. Daytona to Stinger, a Testarossa to Cheetah.

Warto zwrócić uwagę na to, że rockstarowa wersja Daytony swoją nazwę zawdzięcza wyrzutni rakiet Stinger, czyli broni, która zniszczyła pojazd Crocketta na początku trzeciego sezonu.

W Vice City Stories po osiągnięciu odpowiedniego poziomu poszukiwań, gracz zostaje narażony na ataki policjantów poruszających się Cheetahem. Nazwiska policjantów z VCDP squad to między innymi…Cracker i Butts.

5. Ekran ładowania

Sprawa jest prosta, jedna z grafik, które możemy oglądać czekając na uruchomienie się gry to w zasadzie kadr z serialu.

6. Znajdźki

Dobrze znane totemy do zbierania w Vice City to nic innego, jak nawiązanie do posążków z kokainą, które widzowie Miami Vice mogli zobaczyć w odcinku Milk Run.

7. Ricardo Diaz

Choć wątek Diaza to raczej nawiązanie do Scarface, również i tu możemy znaleźć lekkie odniesienie do Miami Vice. Wprowadzony w sezonie piątym El Gato przypomina Diaza nie tylko z wyglądu, ale także z zachowania. Głosu postaci gangstera użyczył Luis Guzman, który odegrał epizodyczną rolę w Miami Vice.

8. Phil Collins

Jedna z największych gwiazd muzyki rozrywkowej pojawiła się we własnej osobie zarówno w Miami Vice, jak i w GTA. Wątki bohaterów granych przez piosenkarza nie są w żaden sposób podobne (w serialu wcielił się w oszusta, w grze wystąpił po prostu jako Phil Collins), jednakże trudno nie odbierać tej analogii jako puszczenia oka do ludzi znających dzieło Michaela Manna. Dodatkowo najsłynniejszą scenę z serialu jest scena, w której główni bohaterowie jadą nocą przez miasto w akompaniamencie In The Air Tonight z solowego debiutu Collinsa. Utwór ten pojawia się w Vice City Stories.

9. Kubańczycy

Gang Kubańczyków odgrywa znaczącą rolę zarówno w Vice City, jak i w Vice City Stories. Jego członków łatwo zidentyfikować dzięki charakterystycznemu ubiorowi. Koszulki części Kubańczyków są żywcem wyjęte z pilotażowego odcinka Miami Vice.

10. Sonny Crockett jako NPC

Po ulicach Vice City spacerują przechodnie najprawdopodobniej wzorowani na Donie Johnsonie w roli Sonny’ego Crocketta.

Oczywiście na pewno pominąłem kilka spraw, w końcu serial liczy 112 odcinków i trudno wychwycić wszystko, co mogło stanowić inspirację dla R*.

Mikrus – Alpine jako LAMP

Siema Ubuntu, ooo Debian! Gdzie CentOS? Ooo tu jesteś! Fajnie Was widzieć. Mam złe wieści, Alpine przyjeżdża na plan.

Wszyscy wiedzą że jestem ogromnym fanem Linuxa i że dla mnie nie ma nigdzie miejsca dla Windowsa, a tym bardziej jakbym miał robić swój serwer (windows pfu!). Jak wiecie z poprzednich notek, że ja i Bonn333 staramy się pokazać zalety innych systemów z rodziny Linux – tym razem jest to Alpine 🙂

Najważniejsza zaleta Alpine to minimalizm. Alpine korzysta z OpenRC, zaś taki Debian czy Ubuntu aktualnie ze systemd, a w dodatku na Alpine postawienie pełnego serwera WWW (np. LAMP – Linux Apache2 MySQL PHP) jest o wiele prostsze niż na innych systemach. W tej notce pokażę Wam jak to bardzo prosto można zrobić. Zapraszam do lektury! 🙂

Zaczynamy więc od instalacji potrzebnych nam pakietów (przy okazji proponuję jak zwykle zaaktualizować system 🙂 ):

apk add apache2 apache2-ssl php7-apache2 mysql mysql-client php7-common php7-iconv php7-json php7-gd php7-curl php7-xml php7-mysqli php7-imap php7-cgi fcgi php7-pdo php7-pdo_mysql php7-soap php7-xmlrpc php7-mcrypt php7-gettext php7-ctype php7-dom

Jak już mamy zainstalowane potrzebne nam pakiety to można ruszać z uruchomieniem bazy danych więc wpisujemy:

mysql_install_db --user=mysql --datadir=/var/lib/mysql

No i MariaDB zainicjowała nam bazę danych w katalogu /var/lib/mysql czyli w domyślnym miejscu. Teraz przyda się dodanie procesów apache2 oraz mariadb do autostartu więc wpisujemy:

rc-update add apache2
rc-update add mariadb

Teraz tak, Ci co są chętni zoptymalizować swoją bazę danych mogą skonfigurować MariaDB oraz Apache2 tak aby zyskać na pamięci RAM, Ci co mają dużą ilość ramu to mogą to pominąć całkowicie.
W pliku /etc/my.cnf.d/mariadb-server.cnf dodajemy pod skip-networking takie o to linijki:

innodb=OFF
default-storage-engine=MyISAM

zaś w pliku /etc/apache2/httpd.conf w linii 29 zmieniamy na:

ServerTokens Minimal

a następnie w pliku /etc/apache2/conf.d/mpm.conf w liniach 28-34:

<IfModule mpm_prefork_module>
StartServers 2
MinSpareServers 2
MaxSpareServers 5
MaxRequestWorkers 200
MaxConnectionsPerChild 200
</IfModule>

Jeśli już jest to gotowe to teraz można uruchomić serwer www oraz bazę danych i ustawić hasło do serwera bazy danych 🙂

rc-service apache2 start
rc-service mariadb start
/usr/bin/mysqladmin -u root password 'password'

W miejsce 'password’ wpisać hasło do bazy mysql jakie ma być ustawione.
Od tej pory można robić sobie powolutku własną stronę www w katalogu /var/www/localhost/htdocs/ który jest domyślnym katalogiem dla stron www. WordPress powinien na takiej konfiguracji działać bez żadnych problemów.

Dlaczego akurat w tym poradniku piszę o Alpine? Kto wie ten wie, kto nie wie ten się teraz dowie, że jestem administratorem w projekcie Mikrus i tam system Alpine Linux działa najlepiej i najwydajniej ze wszystkich. Osobiście polecam poeksperymentować z każdym systemem, a później wybrać jeden ze wszystkich, taki z którym najlepiej się współpracuje i w jego kierunku się rozwijać. Jak to powiedział mój dawny nauczyciel ze szkoły średniej, by wybrać jeden system i powoli stawać się specjalistą z zakresu tego systemu 🙂 Miłej zabawy!

PS. Kto zejdzie tak nisko z pamięcią ram?

Twoje źródło, wolne źródło #2 – Domoticz i Mikrus

Co jak co, ale jako admin Mikrusa muszę zadbać o to żeby coś nowego zawsze było. Ostatnio zacząłem bawić się Domoticzem, lecz po kilku próbach instalacji dałem sobie spokój, tak na kilka dni. Nie uwierzycie nawet, po kilku dniach postanowiłem wziąć się do tematu wraz z Maćkiem Mirotą „od dupy strony” i poszukałem paczki .tgz z domoticzem no i znalazłem 🙂

Mając już tą paczuszkę wykonujemy polecenia:

mkdir /opt/domoticz
cd /opt/domoticz
wget https://releases.domoticz.com/releases/release/domoticz_linux_x86_64.tgz
tar -xzvf domoticz_linux_x86_64.tgz

Jeszcze tak na pocżątku to przydałoby się zainstalować bibliotekę lsb (Debian/Ubuntu: apt install lsb | CentOS: yum install lsb | Arch Linux: pacman -S lsb).
Okej, rozpakowane, to teraz czas nadać prawa uruchamiania i edytować konfigurację 🙂

chmod +x domoticz.sh
nano domoticz.sh

No i tutaj Maciek zaczął bawić się edycją pliku poprawiając to tak jak ma być. Zamiast nano można użyć także vima bądź innych programów. Teraz trzeba edytować linijki takie jak:

– linia 17: USERNAME=root
– linia 21: DAEMON=/opt/domoticz/$NAME
– linia 24 i 25:
DAEMON_ARGS=”$DAEMON_ARGS -www 20109″
DAEMON_ARGS=”$DAEMON_ARGS -sslwww 30109″

gdzie te porty to port 20ID z czego ID to ID serwera vps np. 20109 oznacza serwer vps o ID 109, zaś 20/30/40 na początku to trzy porty wychodzące np. 20109, 30109, 40109.

Teraz poleceniem cp /opt/domoticz/domoticz.sh /etc/init.d/ kopiujemy konfigurację domoticza do właściwego katalogu. Jak już będzie to gotowe to warto sprawdzić czy to działa, więc wpisujemy systemctl enable –now domoticz.sh oraz /etc/init.d/domoticz.sh start. Aby się upewnić że to działa można wpisać polecenia ps -A oraz netstat -tupln i sprawdzić czy proces domoticz działa oraz czy porty które zostały podane działają.

Działa? Działa! Także zatem projekt „Mikrusowy Domoticz” mogę uznać za zamknięty 🙂 W następnej mojej notce postaram się zrobić coś z połączeniem Volumio oraz Domoticza i może coś ekstra 🙂