Takovej selfhosting Notionu bez fancy tabulek.
Outline je open-source nástroj pro tvorbu a správu interní dokumentace a znalostních bází.

Použité technologie

Nginx

Nginx je výkonný webový server a reverzní proxy, který se používá pro obsluhu statického obsahu, směrování požadavků na backend služby a vyvažování zátěže. Je známý svou rychlostí, nízkou spotřebou paměti a spolehlivostí při vysoké zátěži.

Outline

Outline je open-source nástroj pro tvorbu a správu interní dokumentace a znalostních bází. Poskytuje jednoduché a přehledné uživatelské rozhraní pro týmovou spolupráci, verzování a rychlé vyhledávání obsahu.

Dex

Dex je open-source identitní služba, která funguje jako „OpenID Connect“ provider. Slouží k centralizovanému ověřování uživatelů a umožňuje propojit různé aplikace s externími identity providery (např. Google, GitHub nebo LDAP).

Postgres

PostgreSQL (Postgres) je pokročilý open-source relační databázový systém. Nabízí podporu pro komplexní dotazy, transakce, indexy, JSON data a rozšiřitelnost pomocí vlastních funkcí, čímž se hodí pro širokou škálu aplikací od menších po enterprise řešení.

Redis

Redis je in-memory databáze a cache systém, který umožňuje velmi rychlý přístup k datům. Často se používá pro ukládání relací, front, výsledků výpočtů nebo jako prostředník pro komunikaci mezi službami díky podpoře publikace a odběru zpráv (pub/sub).

Docker / Docker Compose

Docker je platforma pro kontejnerizaci aplikací, která umožňuje spouštět software izolovaně s veškerými závislostmi. Docker Compose pak usnadňuje definování a správu vícekontejnerových aplikací pomocí jednoduchého konfiguračního souboru.

Diagram

Postřehy

Outline

Outline neumožňuje přihlašování pomocí uživatelského jména a hesla, což je poněkud nepříjemné. Musí se nakonfigurovat jedna z podporovaných služeb. Aplikace umí pracovat se Slack identitami, Google identitami a dalšími poskytovateli. Pokud nemůžete použít žádnou z těchto služeb, je tam naštěstí možnost Magic Link via Email. Je to sice nepříjemné, ale funkční řešení. Pokaždé, když se chcete přihlásit, pošle vám aplikace email s přihlašovacím odkazem. V mém setupu jsem se rozhodl použít Dex jako OIDC službu, přes kterou se mohu přihlašovat pomocí emailu a hesla.

Dex

Dex je velmi minimalistický, takže nemá webové rozhraní. Navíc jeho dokumentace je hodně nekvalitní. Nejjednodušším způsobem, jak vše rozchodit, je přidat statického klienta a uživatele přímo do konfiguračního souboru. Musíte si ale vytvořit bcrypt hashovaná hesla. Vycházel jsem z tohoto návodu.

SMTP

Aby fungovalo odesílání emailů, je potřeba nakonfigurovat SMTP server. Pokud žádný po ruce nemáte, můžete použít váš Gmail účet. V nastavení Gmailu se musí vytvořit aplikační klíč, který se pak vloží do .env souboru do SMTP sekce.

Setup

.env

URL=https://outline.<domain.com>
PORT=3050
WEB_CONCURRENCY=1
SECRET_KEY=<secret key>
UTILS_SECRET=<utils secret>
DATABASE_URL=postgres://outline:<db password>@outline-postgres:5432/outline
PGSSLMODE=disable

POSTGRES_USER=outline
POSTGRES_PASSWORD=<db password>
POSTGRES_DB=outline

REDIS_URL=redis://outline-redis:6379

FILE_STORAGE=local

FORCE_HTTPS=true

OIDC_CLIENT_ID=outline
OIDC_CLIENT_SECRET=<oidc client secret>
OIDC_AUTH_URI=https://auth.<domain.com>/dex/auth
OIDC_TOKEN_URI=http://dex:5556/dex/token
OIDC_USERINFO_URI=http://dex:5556/dex/userinfo
OIDC_USERNAME_CLAIM=email
OIDC_DISPLAY_NAME=OIDC Provider
OIDC_SCOPES=openid profile email

SMTP_SERVICE=gmail
SMTP_USERNAME=<you>@gmail.com
SMTP_PASSWORD="<app code>"
SMTP_FROM_EMAIL=<you>@gmail.com

RATE_LIMITER_ENABLED=true
RATE_LIMITER_REQUESTS=1000
RATE_LIMITER_DURATION_WINDOW=60

ENABLE_UPDATES=true
DEBUG=http
LOG_LEVEL=info

DEX Config (config.yaml)

issuer: https://auth.<domain.com>/dex

storage:
  type: sqlite3
  config:
    file: /var/dex/dex.db

web:
  http: 0.0.0.0:5556

staticClients:
  - id: outline
    redirectURIs:
      - "https://outline.<domain.com>/auth/oidc.callback"
    name: "Knowledge Base"
    secret: <oidc client secret>

oauth2:
  skipApprovalScreen: true

enablePasswordDB: true

staticPasswords:
  # Admin
  - email: "<admin>@gmail.com"
    hash: "<bcrypt password hash>"
    username: "admin"
    userID: "admin-001"

  - email: "<user>@gmail.com"
    hash: "<bcript password hash>"
    username: "user"
    userID: "user-001"

# Pro debug
logger:
  level: "info"
  format: "text"

Docker Compose

services:
  outline:
    image: docker.getoutline.com/outlinewiki/outline:latest
    env_file: ./.env
    ports:
      - "3050:3050"
    expose:
      - "3050"
    volumes:
      - storage-data:/var/lib/outline/data
    depends_on:
      - outline-postgres
      - outline-redis

  outline-redis:
    image: redis
    env_file: ./.env
    expose:
      - "6379"
    volumes:
      - ./redis.conf:/redis.conf
    command: ["redis-server", "/redis.conf"]
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 10s
      timeout: 30s
      retries: 3

  outline-postgres:
    image: postgres
    env_file: ./.env
    expose:
      - "5432"
    volumes:
      - database-data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD", "pg_isready", "-d", "outline", "-U", "user"]
      interval: 30s
      timeout: 20s
      retries: 3

  dex:
    image: dexidp/dex:v2.37.0
    ports:
      - "5556:5556"  # Vystaveno pro nginx proxy
    expose:
      - "5556"
    volumes:
      - ./dex-config:/etc/dex:ro  # Read-only mount konfigurace
      - dex-data:/var/dex         # Persistentni SQLite databáze
    command: ["dex", "serve", "/etc/dex/config.yaml"]
    healthcheck:
      test: ["CMD", "wget", "--no-verbose", "--tries=1", "--spider", "http://localhost:5556/dex/healthz"]
      interval: 30s
      timeout: 10s
      retries: 3
    restart: unless-stopped

volumes:
  storage-data:
  database-data:
  dex-data:

Nginx

auth.

server {
    listen 80;
    server_name auth.<domain.com>;

    # P┼Öesm─Ťrov├ín├ş HTTP na HTTPS
    return 301 https://$server_name$request_uri;
}

server {
    listen 443 ssl http2;
    server_name auth.<domain.com>;

    # SSL certifik├íty (upravte cestu podle va┼í├ş konfigurace)
    ssl_certificate /etc/nginx/ssl/<domain.com>/fullchain.pem;
    ssl_certificate_key /etc/nginx/ssl/<domain.com>/privkey.pem;

    # SSL konfigurace
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384;
    ssl_prefer_server_ciphers on;
    ssl_session_cache shared:SSL:10m;

    # Proxy nastaven├ş pro Home Assistant
    location / {
        proxy_pass http://<service ip>:5556;
        proxy_set_header Host $http_host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";

        # Timeout nastaven├ş
        proxy_connect_timeout 60s;
        proxy_send_timeout 60s;
        proxy_read_timeout 60s;

        # Buffering nastaven├ş
        proxy_buffering off;
        proxy_request_buffering off;
    }

    # Logov├ín├ş
    access_log /var/log/nginx/auth.<domain.com>.access.log;
    error_log /var/log/nginx/auth.<domain.com>.error.log;
}

outline.

server {
    listen 80;
    server_name outline.<domain.com>;

    # P┼Öesm─Ťrov├ín├ş HTTP na HTTPS
    return 301 https://$server_name$request_uri;
}

server {
    listen 443 ssl http2;
    server_name outline.<domain.com>;

    # SSL certifik├íty (upravte cestu podle va┼í├ş konfigurace)
    ssl_certificate /etc/nginx/ssl/<domain.com>/fullchain.pem;
    ssl_certificate_key /etc/nginx/ssl/<domain.com>/privkey.pem;

    # SSL konfigurace
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384;
    ssl_prefer_server_ciphers on;
    ssl_session_cache shared:SSL:10m;

    # Proxy nastaven├ş pro Home Assistant
    location / {
        proxy_pass http://<service ip>:3050;
        proxy_set_header Host $http_host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";

        # Timeout nastaven├ş
        proxy_connect_timeout 60s;
        proxy_send_timeout 60s;
        proxy_read_timeout 60s;

        # Buffering nastaven├ş
        proxy_buffering off;
        proxy_request_buffering off;
    }

    # Logov├ín├ş
    access_log /var/log/nginx/outline.<domain.com>.access.log;
    error_log /var/log/nginx/outline.<domain.com>.error.log;
}

The post Outline – selfhostovaná znalostní báze first appeared on Hard Wired.

Článek navazuje na Gitea v Dockeru s daty na Synology a Gitea na veřejné subdoméně. Tentokrát si ukážeme, jak vytvořit nový soukromý repozitář a posílat do něj změny.

Předpoklady

• Máme funkční Giteu na vlastní subdoméně, do které se dokážeme přihlásit
• Byly provedeny všechny kroky z předchozích návodů
• Článek se zaměřuje na Windows ale na Linuxu to bude to samé nebo hodně podobné
• Na počítači máme funkční SSH a GIT.

Vytvoření soukromého repozitáře

Přihlásíme se do naší Gitey. Pluskem zvolíme nový repozitář. Zadáme název repozitáře, soukromy-repo-na-smazani. Vybereme Nastavit repozitář jako soukromý a potvrdíme. Vytvoří se prázdný repozitář.

Vytvoření SSH klíče

Pro komunikaci s repozitářem budeme používat SSH. Budeme muset vytvořit pár klíčů, soukromý a veřejný. Soukromý bude u nás na počítači a veřejný budeme nahrajeme k repozitáři, jako přístupový.

Ujistíme se že v c:\Users\<username> máme složku .ssh. Poté v terminálu zadáme příkaz na vygenerování klíče pro přístup do Gitea.

ssh-keygen -t rsa -b 4096 -C "<váš email>" -f ~/.ssh/gitea-example-com

To ve složce .ssh vytvoří dva soubory. gitea-example-com a gitea-example-com.pub. Ten druhý musíme nahrát k repozitáři.

Přidání klíče do Gitea repozitáře

Otevřeme si repozitář. Nastavení > Klíče pro nasazení > Přidat klič pro nasazení. Pojmenujeme si ho, například Domácí klíč. A obsah gitea-example-com.pub zkopírujeme do pole Obsah. Nesmíme zapomenout zaškrtnout volbu Povolit zápis a potvrdit.

Nastavení SSH na počítači

Pokud ve složce c:\Users\<username>\.ssh nemáte soubor config, vytvořte ho a přidejte následující.

Host gitea.example.com
  HostName gitea.example.com
  User git
  Port 222
  IdentityFile c:\Users\<username>\.ssh\gitea-example-com
  IdentitiesOnly yes

Pro hosta gitea.example.com se nastaví odpovídající host name, uživatel, port pro připojení a cesta k privátnímu klíči. Volba IdentitiesOnly zajistí, že pro konkrétního hosta se použijí parametry, které jsou nastaveny.

Připojení repozitáře

Buď můžete připojit už existující repozitář z vašeho počítače, nebo vytvoříte nový. Vytvoříme nový.

Vytvořte složku kde bude nový repozitář. Obecně se pojmenuje názvem repozitáře co jsme vytvořili na naší Gitea.

mkdir soukromy-repo-na-smazani

Přesuneme se do něj.

cd soukromy-repo-na-smazani

Inicializujeme prázdný repozitář.

git init

Vytvoříme první soubor README.md.

touch README.md

Vytvoříme hlavní větev main.

git checkout -b main

Přidáme soubor README.md do git repozitáře.

git add README.md

Vytvoříme první commit.

git commit -m "První commit"

Napojíme náš repozitář z Gitea.

git remote add origin git@gitea.example.com:<gitea username>/soukromy-repo-na-smazani.git

Odešleme změny do vzdáleného repozitáře.

git push -u origin main

Když se nyní podíváme do repozitáře na gitea.example.com, uvidíme náš první commit.

The post Gitea a první soukromý repozitář first appeared on Hard Wired.

Volné pokračování Gitea v Dockeru s daty na Synology. Tentokrát nastavíme aby nám naše self-hostovaná Gitea jela na naší veřejné doméně.

Předpoklady

• Máme nainstalovanou Giteu podle předchozího návodu.
• Máme koupenou vlastní doménu. (pro tutoriál to bude example.com)
• Používáme Nginx jako reverzní proxy.
• Máme přistup do routeru nebo možnost přesměrovávat porty.
• Už jste Giteu jednou spustili a nastavili admin účet.

Nastavení reverzní proxy

Vytvoříme soubor gitea.example.com.

nano /etc/nginx/sites-available/gitea.example.com

server {
    listen 80;
    server_name gitea.example.com;

    location / {
        return 301 https://$host$request_uri;
    }
}

server {
    listen 443 ssl;
    server_name gitea.example.com;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    location / {
        proxy_pass http://:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Při zadání gitea.example.com budou všechny požadavky přesměrovávány na server, kde sedí Gitea a naslouchá na portu 3000. Také se automaticky provede přesměrování z HTTP na HTTPS.

Certifikáty jsou pomocí Let's Encrypt a Certbot, ale to je na jiný návod.

Poté je potřeba dostat symlink do /etc/nginx/sites-enabled.

sudo ln -s /etc/nginx/sites-available/gitea.example.com /etc/nginx/sites-enabled/

Pak je dobré zkontrolovat, jestli Nginx naši novou konfiguraci vezme za svou.

sudo nginx -t

Jestli je vše OK, tak bude potřeba Nginx restartovat.

sudo systemctl restart nginx

Od teď bude gitea.example.com směrovat na naši Giteu.

Nastavení Gitea

Předpoklad je, že Gitea běží v kontejneru. Musíme upravit nastavení. Do Docker kontejneru se můžete dostat pomocí příkazové řádky docker exec -it <container_name_or_id> /bin/bash. Pokud máte rozchozený Portainer, stačí v něm kliknout na ikonku shellu a připojíte se do kontejneru jako root.

Po připojení do kontejneru bude pravděpodobně jako uživatel root. Gitea (v závislosti na typu image) má data uložena v /data. Ale jako uživatel git. Proto než začnete něco měnit, tak je dobré se přepnout za uživatele git. To provedete pomocí su git.

Bude potřeba udělat pár úprav v souboru app.ini, ten se nachází v /data/gitea/conf. (v Gitea kontejneru je dostupný editor VI)

DOMIAN = gitea.example.com
SSH_DOMAIN = gitea.example.com
ROOT_URL = https://gitea.example.com

Tím nastavíme Giteu na naši doménu.

Je předpoklad, že je to soukromý git server, takže nechceme aby se tam mohli lidé samovolně registrovat. Takže je potřeba vypnout registrace.

DISABLE_REGISTRATIONS = true

Poté je potřeba kontejner restartovat.

Přesměrování portů

Gitea cotainer (pokud jste to nezměnili) propaguje porty 3000 (web) a 222 (ssh). Proto je potřeba zajistit aby byl port 222 zvenku dostupný a přesměrovával na server kde Gitea sedí. Jestli máte domácí router který sedí na veřejné IP adrese tak provedete přesměrování portů na něm.

Závěr

Existují ještě další nastavení, ale po těchto pár krocích by už měla Gitea fungovat na vaší doméně.

The post Gitea na veřejné subdoméně first appeared on Hard Wired.

Gitea je self-hostovaná varianta Bitbucketu nebo GitHubu. V následujícím krátkém návodu se podíváme jak nainstalovat Giteu pomocí Dockeru a ukládat data na Synology NAS.

Prerekvizity

• Nainstalovaný a nastavený Docker
• Nainstalovaný a nastavený Synology NAS

Myšlenka

Pro spuštění Gitea serveru použijeme docker compose. Gitea bude používat PostgreSQL databázi. Pro ukládání dat jak pro Giteu, tak i pro Postgres, použijeme docker volumes. Docker volumes nebudou lokální, ale přes protokol NFS budou směřovat na Synology NAS.

Pro potřeby tutoriálu bude mít server IP adresu 192.168.10.1 a Synology NAS 192.168.10.2.

Nastavení Synology

Ovládací panel > Souborové služby > NFS povolte službu NFS.

Ovládací panel > Sdílená složka > Vytvoření sdílené složky. Název docker-volumes. Nepřiřazujeme oprávnění pro uživatele nebo skupiny.

Klikneme na složku docker-volumes a zvolíme upravit. Poté Oprávnění NFS. Klikneme na tlačítko Vytvořit. Do pole Název hostitele nebo IP adresa vložíme IP adresu našeho serveru, tedy 192.168.10.1. Tím umožníme našemu serveru přístup k této složce. Dále nastavíme:

• Oprávnění: Čtení/Zápis
• Squash: Žádné mapování
• Zabezpečení: sys
• Povolit asynchronní
• Povolit připojení z portů bez oprávnění (porty vyšší než 1024)
• Umožňuje uživatelům přístup k připojeným podsložkám

A uložíme.

Poté otevřeme File Station a v naší složce docker-volumes vytvoříme následující podsložky:

• gitea-data
• gitea-postgres

To je na Synology vše.

docker-compose.yaml

Konfigurační soubor vytvoří síť gitea kde na sebe uvidí kontejnery gitea a gitea-db. Vytvoří dva volumes a pomocí protokolu NFS je nasměruje na námi sdílenou složku v Synology NAS.

Docker-compose soubor můžeme spustit pomocí docker-compose up -d. Pokud máte na serveru nainstalovaný a spuštěný Portainer, tak jde docker-compose konfigurace spustit jako stack.

Webové rozhraní poté bude přístupné na http://192.168.10.1:3000.

networks:
  gitea:

volumes:
  gitea-data:
    driver: local
    driver_opts:
      type: nfs
      o: addr=192.168.1.251,rw
      device: ":/volume1/docker-volumes/gitea-data"

  gitea-postgres:
    driver: local
    driver_opts:
      type: nfs
      o: addr=192.168.1.251,rw
      device: ":/volume1/docker-volumes/gitea-postgres"

services:
  server:
    image: gitea/gitea:latest
    container_name: gitea
    environment:
      - USER_UID=1000
      - USER_GID=1000
      - GITEA__database__DB_TYPE=postgres
      - GITEA__database__HOST=gitea-db:5432
      - GITEA__database__NAME=gitea
      - GITEA__database__USER=gitea
      - GITEA__database__PASSWD=supersecretpassword
    restart: always
    networks:
      - gitea
    volumes:
      - gitea-data:/data
      - /etc/timezone:/etc/timezone:ro
      - /etc/localtime:/etc/localtime:ro
    ports:
      - "3000:3000"
      - "222:22"
    depends_on:
      - gitea-db

  gitea-db:
    image: postgres:16
    container_name: gitea-db
    restart: always
    environment:
      - POSTGRES_USER=gitea
      - POSTGRES_PASSWORD=supersecretpassword
      - POSTGRES_DB=gitea
    networks:
      - gitea
    volumes:
      - gitea-postgres:/var/lib/postgresql/data

The post Gitea v Dockeru s daty na Synology first appeared on Hard Wired.

Grammar detailists beware.

Hacky carky chybi. Jsem sice rodily cech, ale spousta textu moji rukou budiz v jazyce anglickem. Je treba brati na zřetel autorovu deformaci profesnim prostredim.

Na zacatek...

• NDA = Non-Disclosure Agreement, v cestine je to mlcenlivost, potazmo dohoda o mlcenlivosti, chcete-li.
• Department = angl. preklad pro "oddeleni"
• accesses = angl. preklad pro pristupy, v tomto kontextu prihlasovaci udaje do konkretniho systemu tak, aby byl zamestnanec schopen pracovat.
• API = Application Programming Interface, laicky to lze popsat jako cast programu, ktera ma otevrenou "zasuvku" pro jine programy, ktere s timto programem muzou dale pracovat tak, jako by se jednalo o soucast.
• PAN = Personal Area Network - Je to forma pripojeni k internetu (zjednoduseno) pres telefon, ale nejen nutne. Muzete i pracovat se soubory.
• CI/CD = Continuous Integration, Continuous Deployment - jedna se o system hlavne pro vyvojare programu. Je to uceleny balik programu, ktere urychluji testovani, verzovani a v urcitych pripadech i automaticke "zverejnovani" novych verzi programu.
• on-call = Dalo by se rici, ze se jedna o stav, kdy mate pracovni telefon v pohotovosti pro pripad, ze bude treba Vasich znalosti na reseni nejakeho pracovniho problemu. Zpravidla je to placene. Jste vlastne sluzebne porad v praci, jen ne fyzicky na pracovisti.

Jedna se o surove myslenky a vzpominky. Zalozeno na realnem zivote, ktery se neodehraval podle predstav. Autorem budiz clovek jinak uvazujici, prosim o zretel.

Rekneme, ze to byla relativne bezna, vzhledem ke Gretine eco lobby zasnezena zima v prazske metropoli, akorat s jednim zasadnim rozdilem.
Ano, pracoval jsem tam. Ve meste, o kterem jsem vzdy touzil, ze budu v nem pracovat, uzivat si kazdodenniho shonu cesty do prace v zacpach Praze vlastni. Parkrat se mi to i stalo.

Nebudu chodit kolem horke kase, ano, uz tam bohuzel nejsem.
Nebo nastesti?

Jak se to vezme.

Chapter one: The leaver

Vse to vlastne zacalo v srpnu 2022. Mel jsem stabilne-nestabilni zamestnani v nenouzove-nouzovem stavu, jelikoz panovala pandemie a vlada si nutne potrebovala vydupat jinak nepotrebny nouzak, ktery vlastne priskrtil i to, co uz bylo davno priskrcene. Ale nechme politiku stranou a soustredme se na myslenky, ktere mi z toho zustaly.

Vazneji receno, nastala mi turbulence v zivote, kterou jsem musel resit a volba padla na hledani jineho, mnohem stabilnejsiho mista.
Jelikoz v domovskem Brne moc prilezitosti nebylo a nekteri, me hodne blizci lide me "nalomili", rozhodl jsem se jit do neznama, do Prahy. Volba padla na jednoho velmi znameho vyrobce 3Dtiskaren. Tusite, mozna, kdo to je.

Ano, Prusa Research, presneji jejich department Prusa Development, v podstate se jednalo o "samostatnou" spolecnost, ktera primo resila vyvoj.

Vse zacalo de facto v zari, odsouhlasili jsme si navzajem tzv. "testovaci tyden", jelikoz jsem nevedel, co od te prace ocekavat. Tento tyden jsem skutecne do prace zde chodil a dostal zadani na vyreseni jedne chyby ve firmwaru SL1S. Co to bylo konkretne rici nemohu, chci si zachovat uctu a v nekterych pripadech i NDA.

Tento tyden dopadl dobre, tuto chybu se mi povedlo najit, vysledovat jeji zdroj a tim tak chybu opravit. Tiskarna se tedy v teto chvili a pro tuto situaci chovala tak, jak bylo dle dokumentace a pozadavku treba.

Chapter two: Good morning mr. Barter, looks like you're running late.

Prvni den v nove praci zacal pomerne "divoce". Vstaval jsem nekdy v 5 rano, v 6 cca autobus do Prahy a aby situace byla dokonala, na prijezdu jsme se zastavili v kolone, uz nekde od Chodova. A to se projevilo i na pozdnim prijezdu, kteremu zabranit neslo.
Nicmene, vse dopadlo dobre, jelikoz jsem prisel cca 10 minut po zacatku.

Nicmene oproti ostatnim jsem uz zdejsi prostredi znal. Bylo mi receno, ze dalsi nove prichozi byli zrovna na prohlidce, kterou jsem absolvoval uz na testovacim tydnu a bylo mi tedy odpusteno.

Vse probihalo v poradku, po veskerych nalezitostech nutnych pro prvni den v praci jsem se znovu shledal s mym primym vedoucim, mimo jine velmi prijemnym panem (mysleno vazne). Pomohl mi odnest veci na me zname pracoviste a ja tak mohl vlastne z fleku zacit pracovat.

Cekalo me me "misto", ktere jsem si vyhledl uz pri testovacim tydnu. Zaujal jsem jej a se znalostmi z minula jsem si zridil velmi rychle ruzne pristupy, accesses a "ozivil" si ucet na jejich internim komunikatoru.

I was ready to work.

Uterni prvni listopad se zacal chylit ke konci a pomalu jsem zacal resit presun na nove, lokalni bydleni.

Na okraji Prahy.

Chapter three: The hacker

Prvni den byl hekticky i v tom smyslu, ze jsem vlastne nemel zajistene ubytovani. Bylo to v jednom byte na okraji Prahy. Prestup na Kacerove z metra na 189 a skoro na konecnou. Radeji si ponecham, kde presne.
Setkal jsem se majitelem, podepsal jsem smlouvu, zabydlel se a chtel si odpocinou.

A zjistil, ze tam vlastne neni internet.

Takto, ne ze bych na nem nejak zivotne zavisel a uprimne znam par lidi, kteri bez internetu nemohou zit, nicmene mi spousta programatoru da za pravdu, ze bez fungujiciho internetu se programuje hodne tezko, zvlaste, pisete-li robota pro ruzne protokoly predavajici zpravy. Je jedno, zda je to email, ci neco podobneho chatu na Facebooku ci Twitteru.

Nebylo tam nic.

Az na jednu restauraci.

Zacal jsem tedy premyslet, jak si alespon castecne zasituji sve bydleni, jelikoz jednoduchou metodou pokus-omyl jsem uhadl relativne trivialni heslo do te restaurace a dovolil si tak pujcit internet. Termin "pujcit" rikam zde zamerne, jelikoz po strance rychlosti jsem se dostal na hodnoty nizsi, nez bylo kdysi davno vytaceny pripojeni.

A ja jako dite jeste pro jistotu odpojoval kabel z pocitace, co kdyby nahodou byl internet pripojenej.

Nicmene, casem se mi povedlo kombinaci androidich telefonu, celkem kvalitniho USB kabelu z Aliexpressu zasitovat pocitac a ja tak mohl pokracovat v soukrome praci. JavaScript byl ku podivu tolerantni k rychlosti a ja tak mohl otestovat moduly do robota, ktery uz ani robotem nebyl, ale mel blize k ucelenemu reseni, chcete-li API.

Nicmene, nekteri lide, hlavne ze socialnich siti, mi nabidli SIM karty s internetem. Moc si cenim, ze mi to nabizeli, ale jakozto clovek snazici se o maximalni samostatnost jsem chtel nejdrive vycerpat veskere moznosti, ktere jsem mel.

Dovezl jsem si tedy z Brna stary router. V podstate to byl TPLink WRT741ND, na kterem bylo naflashovane openWRT. Takze, jak to maji admini radi, SSH a /etc/config/network, potazmo /etc/config/dhcp.

To se neukazalo jako funkcni reseni.

Jako druhe reseni se mi osvedcil kdysi davno pribuzneho Samsung s "petkovym" androidem. Pres soukromy notebook jsem si hral trochu s pripojenim pres PAN a dostal to do funkcniho stavu.

A takhle jsem zacal fungovat v podsate do konce ledna. Nicmene, pendloval jsem mezi "Praglem" a "Schallingrattem" kazde pondeli a kazdy ctvrtek.

V pondeli ve 4 rano,na budika a v 5 RegioJetem v Lowcostu do Prahy s misty nekvalitnim spankem, ve ctvrtek zpet domu, ale o pul 4.

A ano, tu SL1S jsem si zapujcil domu. Jako vybaveni nutne pro vyvoj firmwaru.

Casem jsem to dostal i do stavu, kdy jsem si od jedne pani v domovskem Brne koupil pojizdny kufr, lehce ho opravil a dostal tak moznost vozit 3Dtiskarny s sebou, v kufru.

Chapter five: Nearby

V podstate jsem jsem v lednu travil cas i hledanim jineho bydleni. To predchozi bylo pro me velmi neoptimalni, hlavne kvuli internetu. V podstate jsem veskere prace delal na koleni a misty si musel popojit k obchodu u zastavky, kde jsem vystupoval z autobusu linky 189 a chytat tam wifi.

Ale take kvuli tomu dobrovolne zustaval v praci, nekdy i 13 hodin denne.

Udelal jsem neco navic pro sebe po zkusenostech a znalostech, ale i se snazil dohnat to, co jsem treba zapomnel, ci se mohl posunout vice dopredu oproti puvodnim planum.

Nicmene, zadarilo se.

Nasel jsem si jiny podnajem a sel do nej. A posunul se do pohodlnejsi casti.
Unor. Brezen.

Nic zasadnejsiho se nestalo, co se tyce prace. Kazdodenni shon, ale autobus a metro jsem vymenil za salinu. Nebo pardon - tramvaj. Mohl jsem si vybrat, zda rano sednu na "socku" (jak tomu nekdy prazsti rikaji - je to vubec pravda, nebo je to urban story?), nebo sednu na tramvaj. Oboji me doveze do prace, jen u metra jsem musel prestupovat na Florenci, coz mi davalo jakysi pocit komplexnosti cesty do prace nebo "domu".

Nicmene, uz jsem se dostaval do pohodlne sfery sveho ziti, kdy jsem mohl (konecne) udelat relativne tradicni vylety do Makra, udelat si nakup a vratit se zpatky na byt zrelaxovat po praci.

At uz modelovanim, ci programovanim.
ale take to dopadlo i tak, ze jsem prisel, dal si sprchu a sel spat. Jen zridkakdy jsem se dostal k modelovani, potazmo vyvoji, nicmene nasel se jeden vikend, kdy jsem tomu skutecne venoval cas.

Chapter six: The Chaos

Az cca do pocatku druheho tydne se nic zvlasniho nedelo, na druhou stranu ano, spousta veci byla neustale dynamicka. Letmo jsem se dotkl i veci v te dobe jeste v rannem pocatku vyvoje. Co se soukromeho casu tyce, uz jsem byl v relativni pohode a klidu.

Nicmene i tak jsem se snazil mimo pracovni dobu promptne resit pripominky a sledoval jsem ze sve vlastni vule interni CI/CD, jak probiha testovani a automatizace, ktera byla de facto moji denni naplni.

Zkratka, byl jsem on-call. Po ruce, ale v omezene mire a snazil se i tak dohnat veci, ktere treba usly, popripade chtely nejaky drobnejsi zasah programatora-devopsaka.

To spatne ale teprve melo prijit.

Zacal jsem si vsimat drobnych nedostatku v konunikaci. Jelikoz byl bohuzel odejit uz v lednu nas predchozi vedouci - ten, ktery me nabiral - komunikace se smrskla z formalni peti, misty ctyr lidi, na ctyri, respektive na tri.

Bohuzel i ja zacal zde "selhavat", co se tyce komunikace. Neopochopeni zadani, spousta dotazovani, snaha pracovat samostatne a misty i drobne poznatky, jak vlastne ti lide fungovali v ramci tymu.

Z nekolika drobnych praci bokem pro jine tymy jsem se seznamil s dalsimi a par mych napadu na zlepseni se bohuzel minulo ucinkem.
V zasade jsem se na zdrojovy kod podival, poznal jsem, ze je misty neoptimalni a navrhl zlepseni, jak to resit spravne, jak to mit dle konvenci.

Programatori z povolani me nejspise budou chapat, v kratkosti.
V zasade jde o to, jak spravne automatizovat instalaci.

Treba Python to ma troska specificke, nicmene oproti JavaScriptu / NodeJS to neni zas tak daleko, v podstate slo o "izolaci" veci pro danou aplikaci od systemu, na coz si pamatuji z predchozich zamestnani - kde se mi to stalo - klient si spatne nastavil prostredi a v te chvili rozbil cely system. Program na instalaci jinych programu prestal z minuty na minutu fungovat a "administratore, res to. Hlavne klientovi nerozbij to, co mu tam bezi."

Chapter seven: The detail

Zacal jsem hodne "bojovat" s nadrizenym. Nikoliv fyzicky, ale jak ma dane zadani vypadat, co tam ma byt. Takze, podivam-li se na to svym analytickym pohledem okorenenym o muj autismus (ano, mel jsem na nej papir, sebrali mi jej, pry jsem sobestacnej...), v podstate jsem komunikoval s clovekem, ktery mel siroke uvazovani, zatimco ja velmi detailni.

Treba rozchodit automatizovane SSH, protoze se sitarum par veci nelibilo a podle praxe by jste jako administratori nemeli mit volne dostupny server se superuzivatelem. Neexistuje.

Zadani treba znelo "Zajistit automaticke predavani klicu", coz jsem vyhotovil, ale treba tam chybel nejaky detail, ktery explicitne nebyl zminen.

Takze ano, zadani jsem formalne splnil, ale melo by to byt resene takto, takto, onakto... To proste v dokumentaci k zadani chybelo, takze i parkrat jsem se musel dotazovat, jak tedy ma vypadat vysledek.

A to tez vzalo spoustu casu.

Jelikoz tento clovek byl v "officu" (prakticky to spis byla dilna s pocitaci a hromadou elektroniky kolem) jen dvakrat tydne, komunikace docela vazla. Z predchozich zkusenosti z tymu dvou lidi - ja a nadrizeny - jsem se snazil udelat co nejvice prace, ale take nedelat ukvapene kroky.

Mozna tusite tu kontradikci. Ano rovna se ne. A naopak.

#define True False

A vysvetlovani zacalo.

Parkrat jsem uz byl "na koberecku", snazice se vysvetlit sve uvazovani, jak resit tu praci a cim zlepsit svuj vlastni vykon.

Chapter eight: Evacuation

Nekdy v polovine dubna doslo k nejhorsimu, a sice meeting s HR, jak se veci budou odvijet dale. Bylo mi receno, ze jina moznost, nez dohoda uz neexistuje.

Takze ano, chteli se me zbavit. Podobny, ne-li stejny zpusob, jako v minule firme.
Zadny vytykaci dopis, zadna snaha o to, jak zlepsit praci. Zadna snaha o to, jak bych tem druhym mohl rozumet lepe a jak pochopit kontext jejich myslenek, coz je kolikrat procesorove narocnejsi operace.

A take zadna reference k tomu dobrovolnemu prescasu, za leden budiz 40 hodin.

V podstate jeden cely tyden prescasu, ktery mi vlastne nikdo nezaplatil. Formalne ani nemusel. Ale jako snahu to akceptovat mohl.

Shrnul-li veskere udalosti, v zasade jsem s tim uz souhlasil. Vedel jsem, ze dojizdet kazde pondelni rano je dlouhodobe neudrzitelne, nehlede na absenci spanku, ktera byla mym vernym pritelem.

Ale nebyl to jedinny duvod.

Zde se naskladalo nekolikero faktoru. Nevim, zda je vhodne o tom hovoriti, ale z vnitrniho prostredi firmy jsem se dozvedel, ze ne, ze je to spis fanouskovske zamestnani.

Na druhou stranu, ano, z jednoho platu jsem vlastne "tahnul" dve bydleni.
Svuj domov 207,7 kilometru ode me a sve prechodne bydleni 5,3 kilometru ode me.

Nicmene doslo k nepchopeni na obou stranach. Oni chteli profesionala, dle me z fleku rozumejiciho dane problematice, zatimco ja jim mohl nabidnout jen pokrocile zkusenosti, byt se schopnosti se zorientovat, popripade si obstarat informace. Uplny zacatecnik jsem v te dobe nebyl ani zdaleka, vedel jsem o vyvoji softwaru, vedel jsem i o automatizaci vyvoje.

Koneckoncu automatizaci testovani firmwaru jsem vcetne podrobne dokumentace realizoval na zaklade tehdy existujicich poznamek z jinych tymu.

Byla to jedna z veci, co me opravdu bavila, nejenze jsem se dostal pomerne hluboko k samotnemu firmwaru, nicmene naucil jsem firemni nastroje primo interagovat s tiskarnou, ktera se vlastne odzkousela sama a tim se prace nutna na rucni testovani mohla investovat jinde. To je pointa automatizace.

Nicmene lehce po polovine tydne jsem uz byl nucen opustit Prahu a vratit se zpet.

Chapter nine: The retrospective

I pres tyto spatnosti doted vzpominam na tuto praci jako jednu z mala, ktera me opravdu bavila. I do te miry, ze jsem byl ochoten investovat nemalou cast sveho soukromeho casu do reseni problemu, jak vyresit automatizaci testovani firmwaru.

V podstate jsem delal DevOps praci, jen doplnenou o vyvoj, ktery treba nebyl tak zajimavy, nicmene byl nedilnou soucasti toho, co se tam delo.

Nicmene, chci to hodnotit i tak pozitivne, byt se hodne velke skraloupy a vymoly na silnici najdou.

• Co me hodne mrzi, je jakasi neochota poznat ten cas, co tam clovek investoval dobrovolne. Je to hodne subjektivni pocit a ano, bude to nahnute tak, ze ne kazdy s tim bude souhlasit.
  Tech 40 hodin mi asi uz nikdo nevrati, natozpak nezaplati, na druhou stranu cast toho kodu moji rukou napsanou tam nejspis je doted (ledaze se to dotycny clovek rozhodl cele vyhodit).
• Osobni pocit z pracovne-uzkeho kolektivu spatny. Bohuzel nebyl jsem jedinny. Konkretni ale byt radeji nechci, opet, chci si zachovat uctu.
• Vladne zde "chaos". Termin "chaos" zminuji zamerne v uvozovkach, protoze ne kazdemu sedne dynamika prostredi, ackoliv me to misty nevadilo.
• Chybela mi exaktnost a detailnost. Ale opet, subjektivni pocit. Predstavte si to tak, ze tatinek programator rekne synovi, aby mu popsal, jak si namazat nutellu na rohlik. Date mi za pravdu, ze kdyz syn rekne "vezmi pomazanku" tatinkovi a ten mu na to odpovi "stala se chyba", asi tusite. Logicky, nemuze vzit pomazanku, kdyz je ta sklenice s nutellou uzavrena vikem. Musite udelat spousty kroku.
  A to zde chybelo. Co konkretne.
• Teamleader failure: Nevim, zda je to muj osobni pocit, ale vlastne doted mi nikdo odtamtud neposlal referenci. Dokonce si ode me nadrizeny vyzadal kontakt na zaslani. Bud zapomnel, anebo se na to vykaslal. Vzhledem k 26. 12. - to druhe.
  Bez ohledu na to, ze na to treba ma obecne clovek pravo, nechal jsem zde hovorit realnou vuli pravnicke osoby.
• Pomerne nedavno se mi dostal do rukou odkaz na YouTube od jednoho pomerne znameho recenzenta. Dozvedel jsem se spousty neprijemnych veci. Na zaklade tohoto si kladu otazku "Chtel bych tam jeste pracovat? Proc to udelali takto? Proc se s tou spolecnosti nedohodli treba na spolupraci? Opravdu jim to za to stalo?" Nechal jsem tam spoustu sveho casu a i kdyz tam treba nekoho konkretne nemusim, porad verim, ze jsou tam uzasni lide, kteri na to treba maji podobny pohled, jako ja. Nechci soudit.
• Z partnerskeho hlediska a mimo profesni zkusenosti, troska jsem touzil, ze tam "nejakou" najdu. Na druhou stranu, asi je to tak dobre, protoze pri pomysleni, ze by ona chtela sedet na gauci se mnou a ja programovat... ona by trpela. Nedejboze, ona by chtela jit treba do virivky a ja chtel tisknout treba nahradni dil do domacnosti.

Ted ty pozitiva.

• Dojizdeni do Prahy z Brna a domu do Brna bylo casove narocne. Nicmene davalo mi to jakysi pocit, ze nejenze byl o moji praci a snahu zajem, ale kdyz si to tak vezmu, brnak mel kapacitu na to nabidnout sve znalosti mimo svoji domovinu. Davalo mi to pocit, ze je o me zajem alespon z pracovniho hlediska a byt je to sebemrskacstvi, to dojizdeni me vlastne i bavilo. Prekonaval jsem dalky, prekonaval jsem sve limity a tak si vlastne dokazal, ze i s poruchou autistickeho spektra - nachylnemu k nestabilite - dobre fungovat i v chaotickem prostredi.
• V podstate znam dalsi system na spravu verzi, coz je dobra zkusenost bez ohledu na ukonceni. Prohloubilo to znalosti a rozumim vnitrnimu fungovani. Dat si ted dohromady Kubernetes a orchestraci kontejnerizace ma ted pro me vetsi smysl, jak ten system vypada, jak ho nastavit... Toto na chodniku nenajdete.
• Ano, poznal jsem tam spousty prijemnych lidi. Vyjma psychologicke nekompatibility - osobne - s konkretnim clovekem, nehodlam zde generalizovat pouze na zaklade negativniho vjemu. Ti lide to treba maji radi, radi tam pracuji bez ohledu na podminky, protoze je to bavi. 3Dtisk je vlastne zivotni styl, ne ze si tam nekde nekdo neco vytiskne, ale davate ostatnim moznost realizovat jejich sny.
• Praha je mesto, jako kazde jine. Ma sve problemy, ma sva pozitiva. I pres tu misty stisnenost ti lide tady jen prozivaji stejny zivot, jako treba v Brne. Ac je to treba chaoticke, chci jen jako autista dokazat, ze i v takovem "chaosu" lze fungovat dobre a netreba se bat.
• Vlastne jsem tam prinesl dobre napady a nektere z nich se zalibily. Na testovacim tydnu jsem se podival hloubeji do nekolika zdrojovych kodu a navrhl opravy. A ty uz tam zustaly.
• Neni to jen prace s firmwarem, ale i bokem. Ac jsem z jazyka C na vysoke skole vyletel s F-kem, zkusenosti zustaly a muj kod v C v tom arduinu je doted soucasti tech testu, i kdyby byl neaktivni. V historii je a to ja pocitam.

Chapter ten: The assesment

Hodnoceni sice uz probehlo a formalne je vice nedostatku, nez pozitiv. Nicmene jedna se o osobni pohled jednoho cloveka, ktery jeste k tomu mel pomerne "davno" papir, na kterym bylo napsany, ze mam o pulkolecka min, nebo vic. Zalezi.

Nicmene jedna drobnost se zapomnela.

Mimo praci, po konci smeny jsem treba jednou sedel i v breznu v kanclu a daval tam dohromady rozbite tiskarny. Kazdy by si rekl, ze odpad patri do odpadu, ale i pres to logo jsem se snazil ty stroje proste zprovoznit.

Jako 3Dtiskar nejen po strance uzivani, ale take i stavby, poskytovani rad a predevsim udrzby stroje v provozuschopne kondici jsem se nemohl jen tak divat na to, jak tam ty Mini lezely smutne v koute a jen cekaly, az je nekdo chnapne a slahne s nimi do odpadaku.
A to i pres to, ze jsem uz tehdy mel problem s odrenymi rucemi a nechybelo mi daleko k tomu je mit vydrene az do krve po ruznych buzirkach a neplanovanych zrychlenich sroubovaku spatnym smerem.

Takze, v podstate jsem opravil i par tiskaren, ktere by jinak nekde skoncily a dal jim druhy zivot. Mozna tam ted nekde spokojene tisknou, protoze prakticky schopne jsou.

Na druhou stranu v popisu prace jsem mel napsano "vyvoj a udrzba firmwaru".

Pro SLA tiskarny.

Ac to bylo vzdaleno tomu, co jsem delat chtel, dalo mi to i jakousi zpetnou vazbu, ze me nejvice bavi prace technika a programatora. V podstate umim "vsechno". Navrhnout si nejaky stroj, vyvinout dilce, vytisknout je, pripravit pro tiskarnu nejen firmware, ale i veci okolo - v podstate postavit si vlastni linku pro vyvojare.

Pridam-li k tomu znalosti cloveka pracujiciho jako pocitacovy spravce a sitovy udrzbar, v podstate jsem schopen postavit podobny system na zelene louce. Co mi k tomu potreba je jen pocitac, internet a tabulka bily cokolady s lentilkami z teska.

Trochu premyslim i tak, ze kdyby mi dnes nekdo z jejich HR zavolal "Dobry den, prehodnotili jsme nase rozhodnuti, chceme Te zpet", popremyslel bych o tom.

Zohlednim-li vsak sve zkusenosti z predchozich textu a tez i recenzi jejich produktu, zacinam vahat.

Je mi to lito, protoze i pres ideologicky nesouhlas to byla prvni prace v zivote, u ktere me bavilo i prescasovat a delat veci navic.
Ano, nejsem dokonaly a mam spoustu vyrobnich zavad, nicmene dnes mi spousta lidi predava slova "Mohli mit jednoho z nejvetsich fanousku do 3Dtisku, ktery tomu opravdu rozumi".

Navrhnout si 3Dtiskarnu, postavit ji a udrzovat ji neni prace na tyden, ale z vlastni zkusenosti na rok. Dal jsem do ni 10 tisic a dodneska stale funguje.

Takze zaverem, mohli mit skutecneho fanouska, zel, uz ho nemaji. Mrzi me to, protoze Prusa Research a Development jsou jinak fajn firmy s fajn lidmi. Ty lidi to take bavi a i tam se najdou myslenkove podobni memu uvazovani.

A toto myslim vazne.

The post The Calamity first appeared on Hard Wired.

O co jde

Uděláme bota co načte webovou stránku, klikne na čudlík a stáhne soubor.

Použijeme k tomu knihovnu Puppeteer a samotný kód budeme pouštět v Dockeru.

Větší podrobnosti a vysvětlení zakládání NodeJs projektu v Dockeru najde v článku NodeJS develompent v Dockeru.

Příprava projektu

Založíme nový projekt:

mkdir puppet
cd puppet
npm init -y

Upravíme package.json a přidáme do něj knihovnu puppeteer:

{
  "name": "puppet",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "start": "node index.js"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "dependencies": {
    "puppeteer": "^19.2.0"
  }
}

Vytvoříme Dockerfile, který použije jako základ obraz s node v16, nainstaluje Chrome prohlížeč a nakopíruje projekt do Docker obrazu.

FROM node:16

RUN apt-get update && apt-get install gnupg wget -y && \
  wget --quiet --output-document=- https://dl-ssl.google.com/linux/linux_signing_key.pub | gpg --dearmor > /etc/apt/trusted.gpg.d/google-archive.gpg && \
  sh -c 'echo "deb [arch=amd64] http://dl.google.com/linux/chrome/deb/ stable main" >> /etc/apt/sources.list.d/google.list' && \
  apt-get update && \
  apt-get install google-chrome-stable -y --no-install-recommends && \
  rm -rf /var/lib/apt/lists/*

ENV PUPPETEER_SKIP_CHROMIUM_DOWNLOAD=true \
    PUPPETEER_EXECUTABLE_PATH=/usr/bin/google-chrome-stable

WORKDIR /app
COPY package*.json .
RUN npm install
COPY . ./

Vytvoříme index.js soubor a necháme ho jen vypsat zprávu do konzole.

touch index.js

console.log('Hello from docker')

Není úplně špatné vytvořit i .dockerignore soubor.

node_modules
Dockerfile
.dockerignore
.git
.gitignore
README.md
docker-compose*

Sestavíme obraz.

docker build -t puppet-app-image .

A spustíme Docker kontejner.

# %cd% je aktuální složka ve Windows, pro jiné systémy použijte adekvátní náhradu

docker run -d --tty --name puppet-app -v %cd%:/app -v /app/node_modules puppet-app-image

--tty parametr je nutný. V opačném případě se Docker kontejner spustí a pak hned úspěšně ukončí. Za normálních okolností předpokládá, že v něm něco poběží a až se to ukončí tak skončí taky. TTY toto chování potlačí.

Jakmile kontejner běží, můžeme se do něj přihlásit:

docker exec -it puppet-app bash

Vevnitř se ocitneme ve složce /app, kde je náš projekt a můžeme zkusit spustit náš program.

nodejs index.js

Měl by nám odpovědět Hello from docker.

Bot

Pro ukázku bude bot stahovat zdrojový kód puppeteeru z githubu. Upravíme index.js následovně.

const puppeteer = require('puppeteer')

;(async () => {
    const browser = await puppeteer.launch({
        headless: true,
        args: ['--no-sandbox'],
    })

    const page = await browser.newPage()
    page.setViewport({ width: 1920, height: 1080 })

    const client = await page.target().createCDPSession()
    await client.send("Page.setDownloadBehavior", {
        behavior: "allow",
        downloadPath: './'
    })

    await page.goto(
        'https://github.com/puppeteer/puppeteer/releases/tag/puppeteer-core-v19.2.0',
        { waitUntil: 'networkidle2' }
    )
    await page.waitForTimeout(1000)

    await page.click('#repo-content-turbo-frame div.mb-3 > details > div > div > ul > li:nth-child(1) > div.d-flex.flex-justify-start.col-12.col-lg-9 > a')
    await page.waitForTimeout(5000)

    await page.screenshot({ path: './screen.jpg', fullPage: true })

    await browser.close()
})()

Naimportujeme do našeho projektu knihovnu puppeteer.

const puppeteer = require('puppeteer')

Budeme volat asynchronní funkce v java scriptu a budeme používat klíčové slovo await, které čeká na provedení asynchronní funkce. Problém je to, že await se může objevit jen v asynchronní funkci. Tudíž náš kód musíme do jedné takové zabalit a rovnou spustit.

;(async () => {
    // code
})()

Vytvoříme nový headless prohlížeč.

const browser = await puppeteer.launch({
    headless: true,
    args: ['--no-sandbox'],
})

Vytvoříme novou stránku/tab a nastavíme rozlišení.

const page = await browser.newPage()
page.setViewport({ width: 1920, height: 1080 })

Pro tuto konkrétní stránku nastavíme automatické stahovaní do určitého adresáře. V našem případě adresář s projektem. Takhle nebudeme vyvolávat dialog pro umístění stahovaného souboru.

const client = await page.target().createCDPSession()
await client.send("Page.setDownloadBehavior", {
    behavior: "allow",
    downloadPath: './'
})

V naší stránce/tabu otevřeme požadovanou github stránku.

await page.goto(
    'https://github.com/puppeteer/puppeteer/releases/tag/puppeteer-core-v19.2.0',
    { waitUntil: 'networkidle2' }
)
await page.waitForTimeout(1000)

Klikneme na odkaz pro stažení a chvíli počkáme, než se soubor stáhne

await page.click('#repo-content-turbo-frame div.mb-3 > details > div > div > ul > li:nth-child(1) > div.d-flex.flex-justify-start.col-12.col-lg-9 > a')
await page.waitForTimeout(5000)

K definování toho na co se má kliknout se používá CSS Selector (draft, mdn). Ten pomocí html elementů, tříd, atributů a dalších dokáže sestavit unikátní cestu k prvku na stránce. Stránky generované nějakým frameworkem umí potrápit i s takhle dlouhým selektorem, jako v tomto případě.

Pak už si jen uděláme momentku, v jakém stavu stránku opouštíme.

await page.screenshot({ path: './screen.jpg', fullPage: true })

A prohlížeč korektně zavřeme.

await browser.close()

Spuštění kódu

V konzoli se připojíme k našemu kontejneru.

docker exec -it puppet-app bash

A spustíme našeho bota.

node index.js

Pokud vše proběhne, jak má, tak ve složce projektu budete mít jak stažený soubor, tak fotku stránky těsně před tím než jste ji opustili.

Toto je velice hrubý nástřel toho, co Puppeteer dokáže na konkrétním případě. Výhodou je, že se opravdu spustí prohlížeč, ve kterém můžeme ovládat i dynamicky generované single page aplikace. Nevýhodou je, že pokud se struktura stránky změní moc, tak musíte upravit i váš kód.

Happy coding!

The post Puppeteer download BOT first appeared on Hard Wired.

Pokud se motáte okolo webového vývoje (frontendy, api a pod...) a používáte JavaScript (respektive NodeJS), tak jste se určitě už setkali s následujícím problémem. Různé projekty jsou napsány pod různými verzemi programovacího jazyka a ne vždy je možné vše upgradovat na poslední verzi.

• Můžete používat knihovny, které ještě nejsou upraveny pro novou verzi.
• Starší verze frameworku s poslední verzí jazyka nefunguje.
• Zpětná nekompatibilita.
• Prostě nejsou peníze nebo není čas zabývat se přechodem a přepisem aplikace na poslední verzi.

Důvodů může být milión, ale klíčové je to, že pokud jste to vy co musí do těchto projektů zasahovat, tak musíte provozovat více verzí jazyka.

Pokud se potýkáte s tímto problémem, tak nehledě na jakém operačním systému se nacházíte, budou scénáře podobné.

Scénář 1 - Jedna verze v systému

Tohle je pro popisovaný problém asi nejhorší situace. Máte v systému jednu verzi jazyka. Všechny projekty, na kterých pracujete, musejí běžet pod touhle verzí. Zpravidla to skončí tak, že verze jazyka bude taková, jakou potřebuje ten nejstarší (legacy) projekt. Může vás to zablokovat na tolik, že nebudete moci použít poslední verze frameworků nebo poslední funkcionalitu, protože nebudou tak starou verzi jazyka podporovat.

Scénář 2 - NVM

Node Version Manager (NVM) je utilita, která vám umožní provozovat více verzí jazyka na jednom stroji a přepínat mezi nimi. Existuje jak pro Linux, MacOs, tak i pro Windows. Ve chvíli kdy se přepínáte mezi verzemi a používáte současně jednu, je to přímočaré a elegantní řešení. Ve chvíli, kdy potřebujete mít několik projektů puštěných naráz, pod různými verzemi jazyka, už samozřejmě vyžaduje určitou míru konfigurace. Ale zrovna k tomuto scénáři nemám moc co říct, protože jsem provozoval jen tu nejprimitivnější formu čistě přepínání mezi verzemi. Každopádně se jedná o funkční řešení.

Scénář 3 - Vagrant

Vagrant od HashiCorp používá pro oddělení prostředí virtualizaci. Vytvoříte předpis, který nakonfiguruje virtuální stroj, ve kterém následně aplikaci vyvíjíte. Je možné nakonfigurovat celý ekosystém, aplikace, databáze, cache atd. Teoreticky je to geniální věc. Nehledě na systém máte předpis, který spustíte na jakémkoliv systému a vytvoří vám stejné prostředí pro vývoj. V praxi to už tak veselé nebylo. Je pravda, že jsem Vagrant použil naposledy před několika lety. Problémy byly zpravidla nějaká specifika operačních systému, zvláště Windows. Nebo situace co se musely řešit "hackem", protože ještě neexistovalo nativní řešení a samozřejmě hromada virtuálních mašin, když bylo prostředí pro vývoj rozsáhle. I tak jsem na tom byl nějakou dobu schopný vyvíjet a šlo to docela dobře. Čas pokročil a určitě byla hromada věcí dotažena. Určitě se jedná o funkční řešení.

Scénář 4 - Docker

Jak už název článku napovídá, budeme řešit Docker. Docker používá kontejnery. Kontejner je softwarová jednotka, která zapouzdřuje kód i s jeho závislostmi. Na rozdíl od standardní virtualizace, nerozebíhá znovu celý operační systém, ale používá operační systém hostitele. Nejlíp to asi vysvětlí přímo citace ze stránek Dockeru.

A container is a standard unit of software that packages up code and all its dependencies so the application runs quickly and reliably from one computing environment to another. A Docker container image is a lightweight, standalone, executable package of software that includes everything needed to run an application: code, runtime, system tools, system libraries and settings.

Container images become containers at runtime and in the case of Docker containers – images become containers when they run on Docker Engine. Available for both Linux and Windows-based applications, containerized software will always run the same, regardless of the infrastructure. Containers isolate software from its environment and ensure that it works uniformly despite differences for instance between development and staging.

from https://www.docker.com/resources/what-container/

V praxi to znamená, že máte v kontejneru souborový systém operačního systému dle libosti. Doinstalujete si potřebné balíčky pro běh vašeho projektu a tento kontejner můžete izolovaně pouštět tam, kde jsou kontejnery podporované. Speciálně Docker funguje pod Linuxem, MacOs i Windows.

+------------++-----------+
|    APP1    ||   APP2    |
+------------++-----------+
+------------++-----------+
|  Bin/Libs  ||  Bin/Libs |
+------------++-----------+
+-------------------------+
|         Docker          |
+-------------------------+
+-------------------------+
|    Operační systém      |
+-------------------------+
+-------------------------+
|         Server          |
+-------------------------+

"Back in my days", když jsem si chtěl na serveru rozjet nějaké služby, buď jsem provozoval nějakou virtualizaci nebo jsem to všechno naplácal do jednoho operačního systému. Jedno ze zásadních úskalí bylo to, že různé služby potřebovaly různé balíky, verze knihoven a míru konfigurace. Pokud člověk nebyl dostatečně obezřetný mohl si "roze***t" celý systém a vše poslat do kytek. V lepším případě byla mašina v jakémsi meta ezo stavu, kdy něco jelo a něco ne.

S Dockerem hromada problémů opadla. Každá služba je izolovaný kontejner, který si své závislosti bere sebou. Pokud něco nefunguje, vadný kontejner se vymaže, ale vše ostatní jede dál. Drtivé množství běžných služeb (wiki, databáze, ...) mají už dnes nachystané a nakonfigurované obrazy. V uvozovkách je stačí jen spustit. Jako všechno si to sebou nese i negativa. Neaktualizované knihovny v kontejneru jsou bezpečnostní riziko. Nebo pokud si nevytváříte kontejner sami tak musíte důvěřovat autorovi, že tam nenasadil nějakou breberku. Ale vždy je něco za něco.

Jak už asi tušíte, z tohoto stručného popisu, použití pro výše popsaný problém bude jasné. Vytvoří se pro projekt Docker kontejner a tak budou všechny závislosti projektu izolovány od hlavního operačního systému. Takhle můžete mít pohodlně puštěné aplikace pod různou verzí NodeJS na jednom stroji. Je to v podstatě jako Vagrant, VirtualBox nebo obecně virtualizace. Akorát teda ne tak úplně.

Nešpinit systém, na kterém vyvíjíte, závislostmi projektu je podle mě dlouhodobě udržitelná cesta.

Plus mají kontejnery dnes ještě jednu výhodu. Cloudové služby vám zpravidla umožňují posílat kontejnery i do produkce.

Čestná zmínka

Výše uvedené scénáře nejsou určitě jediné, ale jsou to ty, se kterými jsem se setkal osobně.

Minimálně ještě existuje možnost vyvíjet na vzdáleném operačním systému přes SSH. Visual Studio Code tento vzdálený vývoj umožňuje. Jako taky možnost, ale za mě teda trochu exotická. Ale když není zbytí, lepší než drátem do oka.

NodeJS projekt v Dockeru

Toto není kompletní návod pro člověka, který se v životě neotřel o Docker nebo o NodeJS a vývoj API. Do takových podrobností článek nejde. Zabývá se jak rozjet projekt v Dockeru a předpokládá už určité znalosti. Pardon.

V první řadě budeme potřebovat nainstalovat Docker. Případně na desktopu (a hlavně na Windows) to bude Docker Desktop.

Pokusíme se rozjet vývoj REST API s použitím ExpressJs.

Pro náš projekt budeme mít následující strukturu.

nodejs-docker-workflow \
    .dockerignore
    .env
    Dockerfile
    index.js
    package.json
    package-lock.json

pakcage.json obsahuje konfiguraci projektu.

{
  "name": "nodejs-docker-workflow",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "start": "node index.js",
    "dev": "nodemon -L index.js"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "dependencies": {
    "express": "^4.18.1"
  },
  "devDependencies": {
    "nodemon": "^2.0.20"
  }
}

V části závislostí budeme pro náš jednoduchý projekt potřebovat pouze balíček express. V rámci vývojových závislostí (devDependencies) budeme používat nodemon. Ten nám umožní restart serveru, pokud se vyskytne změna v hlídaném adresáři.

index.js obsahuje kód našeho REST API.

const express = require('express')

const app = express()

app.get('/', (req, res) => {
    res.send({
        data: {
            message: 'Hello world!',
            exclamation: '!!!',
        },
    })
})

const port = process.env.PORT || 3000

app.listen(port, () => console.log(`listening on port ${port}`))

Primitivní API vracející "Hello world!".

Dockerfile obsahuje sestavení našeho obrazu kontejneru.

FROM node:16
WORKDIR /app
COPY package*.json .
RUN npm install
COPY . ./
ENV PORT 3000
EXPOSE $PORT
CMD ["npm", "run", "dev"]

FROM node:16 říká, že použijeme základní image, na kterém je už nachystán NodeJS verze 16.

WORKDIR /app nás v rámci kontextu přesune do složky /app.

COPY package*.json . překopíruje do obrazu do /app soubor package.json.

RUN npm install spustí instalaci závislostí na základe package.json.

COPY . ./ překopíruje soubory z aktuálního adresáře do obrazu do /app.

ENV PORT 3000 vytvoří proměnou prostředí.

CMD ["npm", "run", "dev"] spustí skript definovaný v package.json, který spustí nodemon.

.dockerignore obsahuje seznam souboru a složek co se nebudou kopírovat do obrazu.

node_modules
Dockerfile
.dockerignore
.git
.gitignore
README.md
docker-compose*

.env je seznam proměnných prostředí, které chceme aplikovat na kontejner.

PORT=4000

Základní projekt máme nachystaný. A sestavíme na základě Dockerfile obraz pro náš kontejner.

docker build -t node-app-image .

Následně pak můžeme překontrolovat, že obraz skutečně existuje.

docker image ls

Obraz je nachystaný a můžeme spustit samotný kontejner.

# WINDOWS %cd%
# POWERSHELL ${pwd}
# MAC, LINUX $(pwd)

# --env PORT=4000
# --env-file ./.env

docker run -p 3000:4000 -d --name node-app --env-file ./.env -v %cd%:/app -v /app/node_modules node-app-image

-p 3000:4000 přesměruje port 3000 z hostitelského systému na port 4000 Docker kontejneru.

-d spustí Docker kontejner na pozadí.

--name node-app pojmenuje kontejner.

--env-file ./.env nastaví proměnné systému na základě souboru .env.

-v %cd%:/app zajistí zrcadlení aktuálního adresáře a jeho změny do /app v kontejneru.

-v /app/node_modules vytvoří volume pro node moduly. Díky tomu se nestane to, že přes zrcadlený adresář pošleme příkaz k jejich smazání v kontejneru. Je to trochu "ohák", ale funční.

node-app-image je název obrazu na základě kterého vytváříme kontejner.

Pokud nedostaneme nějaké chybové hlášení, můžeme zkontrolovat, že vše jede.

Můžeme se podívat na aktuálně běžící kontejnery.

docker ps

A můžeme také zkontrolovat logy pro konkrétní kontejner.

docker logs node-app

Když do prohlížeče zadáme localhost:3000 dostaneme následující.

{"data":{"message":"Hello world!","exclamation":"!!!"}}

Pokud v souboru index.js upravíme odpověď serveru, nodemon na to zareaguje a restartuje API s aktuální změnou.

Jestliže se potřebujeme "přihlásit" dovnitř kontejneru do příkazové řádky, použijeme docker exec.

docker exec -it node-app bash

V této chvíli máme plně funkční NodeJS projekt v Dockeru. Pokud přidáme nebo odebereme balíčky, musím znovu sestavit obraz pomocí docker build -t node-app-image . a Docker kontejner spustit.

Předtím je teda nutné kontejner zabít, to uděláme pomocí docker rm.

docker rm node-app -fv

-fv odstraní i běžící kontejner (nemusíme zastavovat) a na něj navázané anonymní volumes (svazky).

Tohle je taková "základní" verze. Spouštění Docker kontejneru, s veškerou konfigurací v příkazové řádce může být po čase otrava. Jednodušším řešením je použití Docker-Compose.

V našem projektu vytvoříme soubor docker-compose.yml.

version: "3"
services:
  node-app:
    container_name: node-app
    build: .
    ports:
      - "3000:4000"
    volumes:
      - ./:/app
      - /app/node_modules
    env_file:
      - ./.env
#    environment:
#      - PORT=4000 

version: "3" je verze zápisu Docker Compose souboru.

node-app: uvozuje sekci našeho kontejneru.

container_name: node-app pojmenuje náš kontejner. Pokud ho nepojmenujeme sami, Docker to udělá za nás.

build: . sestaví obraz pomocí Dockerfile.

ports: přesměrování portů.

volumes: seznam volumes.

env_file: nastavuje proměnné prostředí.

Docker Compose soubor jen kopíruje to, co jsme nastavovali pro docker run. Ale takhle nám zůstane nastavení pěkně a strukturovaně uloženo.

Předpis spustíme pomocí příkazu docker-compose.

docker-compose up -d

Pokud přidáme parametr --build, tak se při každém spuštění znovu sestaví obraz.

docker-compose up -d --build

Pomocí docker-compose provádíme i smazání.

docker-compose down -v

-v jako v předchozím případě smaže i připojené anonymní volumes.

Tohle je už o něco lepší verze, ale nepočítá s tím, že bychom chtěli různá prostředí. Například development a production. Budeme muset upravit Dockerfile, docker-compose.yml a přidat docker-compose.dev.yml a docker-compose.prod.yml.

Do Dockerfile přidáme podmínku pro různá prostředí.

FROM node:16
WORKDIR /app
COPY package*.json .

ARG NODE_ENV
RUN if [ "$NODE_ENV" = "development" ]; \
        then npm install; \
        else npm install --only=production; \
        fi

COPY . ./
ENV PORT 3000
EXPOSE $PORT
CMD ["node", "index.js"]

ARG NODE_ENV definujeme použití argumentu NODE_ENV.

RUN if [ "$NODE_ENV" = "development" ]; \ na základě aktuální typu prostředí provedeme klasický npm install nebo produkční.

CMD ["node", "index.js"] je příkaz do produkčního prostředí, protože nespouštíme nodemon. Každopádně ho stejně budeme definovat znovu v Docker Compose souborech.

docker-compose.yml trošku zeštíhlíme a necháme v něm jen společná nastavení pro všechna prostředí.

version: "3"
services:
  node-app:
    container_name: node-app
    build: .
    ports:
      - "3000:4000"
    environment:
      - PORT=4000  

docker-compose.dev.yml nastavím pro naše development prostředí.

version: "3"
services:
  node-app:
    build:
      context: . 
      args:
        NODE_ENV: development
    volumes:
      - ./:/app
      - /app/node_modules
    environment:
      - NODE_ENV=development  
    command: npm run dev

Všimněte si, že jsme rozšířili definici build a přidali argument NODE_ENV, který se používá v Dockerfile. Nastavení volumes je stejné jako předtím a přepsali jsme CMD v Dockerfile na náš development příkaz.

docker-compose.prod.yml bude jednodušší, protože pro produkci nepotřebujeme zrcadlit adresáře.

version: "3"
services:
  node-app:
    build:
      context: . 
      args:
        NODE_ENV: production
    environment:
      - NODE_ENV=production
    command: node index.js

Principiálně je to to samé co docker-compose.dev.yml.

Pokud budeme chtít spustit development verzi, zavoláme.

docker-compose -f docker-compose.yml -f docker-compose.dev.yml up -d

Popřípadě, pokud chceme spustit i vytváření obrazu.

docker-compose -f docker-compose.yml -f docker-compose.dev.yml up -d --build

Odstranění kontejneru provedeme promocí.

docker-compose -f docker-compose.yml -f docker-compose.dev.yml down -v

Pro produkční build to bude analogické.

docker-compose -f docker-compose.yml -f docker-compose.prod.yml up -d
docker-compose -f docker-compose.yml -f docker-compose.prod.yml up -d --build
docker-compose -f docker-compose.yml -f docker-compose.prod.yml down -v

TADÁ a to je vše přátele. Aplikace funguje pořád stejně, ale už můžeme rozlišovat mezi development a production prostředtím.

ad1) Článek popisuje pouze absolutní základ, pravá síla Dockeru se projeví ve chvíli, kdy si nakonfigurujete kompletní ekosystém a budete ho schopni jednoduše replikovat.

ad2) Článek ukazuje situaci, kdy nebudete mít na svém stroji nainstalován NodeJS a nepustíte npm install na svém stroji. Tím si nevygenerujete package-lock.json. To může být problém při generování produkčních kontejnerů. package-lock.json obsahuje deterministický popis závislostí. Do produkce chcete jít s takovým stromem závislostí, který už máte odzkoušený. Pro doplnění citace z docs.npm.com.

package-lock.json is automatically generated for any operations where npm modifies either the node_modules tree, or package.json. It describes the exact tree that was generated, such that subsequent installs are able to generate identical trees, regardless of intermediate dependency updates.

Describe a single representation of a dependency tree such that teammates, deployments, and continuous integration are guaranteed to install exactly the same dependencies.

from https://docs.npmjs.com/cli/v8/configuring-npm/package-lock-json

Proto je vhodnější postup na hostitelské systému používat npm i pro instalaci nových balíčku do projektu. Tím se bude generovat i package-lock.json. Toto nijak neomezuje používání rozličných verzí NodeJS v kontejnerech.

ad3) Docker se chová tak, že spustí příkaz a když doběhne, tak se vypne. V případě, že rozjíždíte NodeJs API, tak je to jedno. Tam se předpokládá, že pouštíte nějaký nodemon nebo něco co udrží API v běhu. Pokud ale chcete vyvíjet něco co neběží ve smyčce a z Dockerfile odeberete CMD příkaz, tak se Docker container spustí a úspěšně ukončí. Jde tím předejít přidáním parametru tty.
Ten zajistí, že se kontejner hned neukončí.

Pro docker-compose:

mydocker:
    tty: true

Pro docker run:

docker run -d --tty ......

The post NodeJS develompent v Dockeru first appeared on Hard Wired.

Těžko by jste asi hledali někoho, kdo nikdy neposlal ani jednu zprávu přes Messenger nebo podobnou službu. Asi můžeme říct, že je to jeden z nejrozšířenějších komunikačních prostředků současnosti.

S rostoucím podílem těchto služeb v oblasti všeobecné komunikace vyvstal i takový nešvar. Hovorově bychom mohli říct "fízlování". V reálu to bude nějaká sada algoritmů, která se snaží na základě klíčových slov, frází nebo nějaké sofistikovanější analýzy rozpoznat závadný či protiprávní obsah. Tyto praktiky se většinou zaštiťují ochranou dětí před XYZ a podobné zavádějící důvody. Ale o problematice svobody slova a práva na soukromí tento příspěvek není.

Klasické textové komunikační služby ukládají vaše zprávy v nešifrované podobě. Nemáte vůbec tušení jak dlouho se vaše data uchovávají a za jakým účelem (většinou marketing) mohou být přeprodávána. A už vůbec nevíte, kdy a kdo, to může použít proti vám. (byť třeba vytržené z kontextu)

Situaci si můžete vylepšit tím, že používáte "end-to-end" šifrované komunikátory. Telegram, Signal, Threema a podobně. Při této metodě komunikace by v ideálním případě zprostředkovatel neměl být schopný zprávy jakkoliv dešifrovat.

Tak je to možná v ideálním světě. V tom našem můžeme narazit na pár úskalí. Musíme zprostředkovateli věřit, že dodává takovou službu jakou inzeruje. I když nemusí vidět přímo obsah zpráv, stále si může uchovávat kdo, kdy a s kým komunikoval. Nepříjemností taky je registrace podmíněná poskytnutím telefonního čísla. Telefonní číslo za určitých podmínek dává smysl a používání aplikace je díky němu komfortnější, ale taky je to další vektor útoku na vaši identitu.

Alternativní možností je zprovoznit vlastní Matrix server. Pokud o tom slyšíte poprvé, můžete prozkoumat Fediverse ekosystém a pořádně se ponořit do králičí nory.

Jen ve zkratce popis na wikipedii.

The fediverse (a portmanteau of federation and universe) is an ensemble of federated (i.e. interconnected) servers that are used for web publishing (i.e. social networking, microblogging, blogging, or websites) and file hosting, but which, while independently hosted, can communicate with each other. On different servers (instances), users can create so-called identities. These identities are able to communicate over the boundaries of the instances because the software running on the servers supports one or more communication protocols which follow an open standard.[1] As an identity on the fediverse, users are able to post text and other media, or to follow posts by other identities.[2] In some cases, users can show or share data (video, audio, text, and other files) publicly or to a selected group of identities and allow other identities to edit other users\' data (such as a calendar or an address book). from https://en.wikipedia.org/wiki/Fediverse

Pro naše účely není tento aspekt úplně klíčový.

Co vlastně získáme tím, že zprovozníme vlastní Matrix server?

• Komunikace používá end-to-end šifrování. Nikdo kromě příjemce by neměl být schopný zprávu vidět.
• Data leží na našem "železe" a v námi kontrolovaném operačním systému. Sami si můžete překontrolovat jak a jaká data jsou v databázi ukládána.
• Starou dobrou registraci s uživatelským jménem a heslem. Nejsou potřeba žádné emaily nebo telefonní čísla.
• Nikdo probíhající komunikaci "nefízluje".
• Kód je open source. Každý do něho může nahlédnout. Možnost úmyslného zanešení nějakého škodlivého kusu kódu je hodně malá. Komunita by jim to brzy omlátila o hlavu.
• Máte na výběr z vícero klientů. I když tohle může být někdy i negativum než pozitivum.
• Moderní klienti moc nezaostávají za předními hráči na trhu. Ano jde poznat, že do toho nebylo nasypáno tolik peněz a „user experience“ není tak „smooth“. To ale nic nemění na tom, že můžete posílat zprávy, fotky, videa, emoji, nálepky, gify nebo provádět video telefonáty. Všechno je technicky funkční.
• Je možné provozovat komunikaci s jednotlivými lidmi, skupinové komunikace nebo vytvářet místnosti.

Výhod se najde asi ještě více, ale tou nejdůležitější vlastní kontrola.

Nevýhod se najde taky dost. Vůbec samotné rozeběhnutí vyžaduje lehce technický „skill“. Plus věci okolo jako domény, reverzní proxy atd.

Tak a teď teda k tomu co a jak je potřeba rozeběhnout.

Rozeběhnout to můžete skoro na čemkoliv, ale já pro naše účely použil RPi 3B+ s SSD diskem. Pro běh jednotlivých služeb použijeme Docker a Docker-Compose. Jak nainstalovat Docker je popsáno v jiném článku na tomto blogu.

Náš stack obsahje následující Docker obrazy.

• portainer/portainer-ce:latest
• matrixdotorg/synapse:latest
• postgres:14
• vectorim/element-web:latest

Portainer slouží jen pro pohodlnější správu Docker kontejnerů.

Jako Matrix server použijeme Synapse. Je to implementace Matrix serveru v Pythonu.

Postgres 14 bude naše databáze. V základu používá Synapse Sqlite3, ale pokud máme tu možnost, bude lepší použít Postgres.

Element je webový klient pro Matrix server.

V domovském adresáři si vytvoříme složku matrix-stack a začneme skládat Docker-Compose soubor.

cd ~
mkdir matrix-stack
nano ./matix-stack/docker-compose.yml

version: '3.3'

services:
  portainer:
    container_name: portainer
    image: portainer/portainer-ce:latest
    restart: always
    ports:
      - "9000:9000"
    volumes:
      - portainer_data:/data
      - /var/run/docker.sock:/var/run/docker.sock

  synapse:
    container_name: synapse
    image: matrixdotorg/synapse:latest
    restart: always
    ports:
      - 8008:8008
    volumes:
      - /var/docker_data/matrix:/data

  postgres:
    container_name: postgres
    image: postgres:14
    restart: unless-stopped
    ports:
      - "5432:5432"
    volumes:
     - /var/docker_data/postgresdata:/var/lib/postgresql/data

    environment:
     - POSTGRES_DB=synapse
     - POSTGRES_USER=synapse
     - POSTGRES_PASSWORD=SUPERSECRETLONGPASSWORD
     - POSTGRES_INITDB_ARGS=--lc-collate C --lc-ctype C --encoding UTF8

  element:
    container_name: element
    image: vectorim/element-web:latest
    restart: unless-stopped
    ports:
      - "80:80"
    volumes:
      - /var/docker_data/element-config.json:/app/config.json

volumes:
  portainer_data:

Pro Synapse místo Sqlite3 použijeme Postgre databázi. Víceméně se standardním nastavením kromě jedné věci.

POSTGRES_INITDB_ARGS=--lc-collate C --lc-ctype C --encoding UTF8

Matrix vyžaduje aby LC_COLLATE a LC_TYPE nastaveny na C. Má to co do činění s akceptováním různých znakových sad.

When LC_CTYPE is C or POSIX, any character set is allowed, but for other settings of LC_CTYPE there is only one character set that will work correctly. Since the LC_CTYPE setting is frozen by initdb, the apparent flexibility to use different encodings in different databases of a cluster is more theoretical than real, except when you select C or POSIX locale (thus disabling any real locale awareness).

Před tím, než pustíme docker-compose, je potřeba udělat ještě pár věcí.

Potřebujeme vygenerovat konfigurační soubor pro Synapse server.

docker run -it --rm \
    -v "/var/docker_data/matrix:/data" \
    -e SYNAPSE_SERVER_NAME=matrix.YOUR_DOMAIN.com \
    -e SYNAPSE_REPORT_STATS=no \
    matrixdotorg/synapse:latest generate

A v nově vygenerovaném souboru předělat Sqlite3 na Postgre. Stačí zakomentovat sekci s Sqlite3 a vložit novou.

database:
  name: psycopg2
  args:
    user: synapse
    password: SUPERSECRETLONGPASSWORD
    database: synapse
    host: postgres
    cp_min: 5
    cp_max: 10

Potom je potřeba vytořit konfigurační soubor pro Element.

sudo nano /etc/docker_data/element-config.yaml

{
    "default_server_config": {
        "m.homeserver": {
            "base_url": "https://matrix.YOUR_DOMAIN.com",
            "server_name": "matrix.YOUR_DOMAIN.com"
        },
        "m.identity_server": {
            "base_url": "https://vector.im"
        }
    },
    "brand": "Element",
    "integrations_ui_url": "https://scalar.vector.im/",
    "integrations_rest_url": "https://scalar.vector.im/api",
    "integrations_widgets_urls": [
        "https://scalar.vector.im/_matrix/integrations/v1",
        "https://scalar.vector.im/api",
        "https://scalar-staging.vector.im/_matrix/integrations/v1",
        "https://scalar-staging.vector.im/api",
        "https://scalar-staging.riot.im/scalar/api"
    ],
    "hosting_signup_link": "https://element.io/matrix-services?utm_source=element-web&utm_medium=web",
    "bug_report_endpoint_url": "https://element.io/bugreports/submit",
    "uisi_autorageshake_app": "element-auto-uisi",
    "showLabsSettings": true,
    "piwik": {
        "url": "https://piwik.riot.im/",
        "siteId": 1,
        "policyUrl": "https://element.io/cookie-policy"
    },
    "roomDirectory": {
        "servers": [
            "matrix.org",
            "gitter.im",
            "libera.chat"
        ]
    },
    "enable_presence_by_hs_url": {
        "https://matrix.org": false,
        "https://matrix-client.matrix.org": false
    },
    "terms_and_conditions_links": [
        {
            "url": "https://element.io/privacy",
            "text": "Privacy Policy"
        },
        {
            "url": "https://element.io/cookie-policy",
            "text": "Cookie Policy"
        }
    ],
    "hostSignup": {
      "brand": "Element Home",
      "cookiePolicyUrl": "https://element.io/cookie-policy",
      "domains": [
          "matrix.org"
      ],
      "privacyPolicyUrl": "https://element.io/privacy",
      "termsOfServiceUrl": "https://element.io/terms-of-service",
      "url": "https://ems.element.io/element-home/in-app-loader"
    },
    "sentry": {
        "dsn": "https://029a0eb289f942508ae0fb17935bd8c5@sentry.matrix.org/6",
        "environment": "develop"
    },
    "posthog": {
        "projectApiKey": "phc_Jzsm6DTm6V2705zeU5dcNvQDlonOR68XvX2sh1sEOHO",
        "apiHost": "https://posthog.element.io"
    },
    "features": {
        "feature_spotlight": true
    },
    "map_style_url": "https://api.maptiler.com/maps/streets/style.json?key=fU3vlMsMn4Jb6dnEIFsx"
}

V horní části souboru upravte pro vaši doménu.

"default_server_config": {
        "m.homeserver": {
            "base_url": "https://matrix.YOUR_DOMAIN.com",
            "server_name": "matrix.YOUR_DOMAIN.com"
        },
        "m.identity_server": {
            "base_url": "https://vector.im"
        }
    }

Tak a teď už můžeme pustit ten docker. Přesuneme se do složky s Docker-Compose souborem a spustíme příkaz docker-compose.

cd ~/matrix-stack
docker-compose up -d

Pokud všechno proběhne dle plánu, tak se můžete zkusit přihlásit do Portaineru a měli byste vidět něco takového.

Teď se potřebujeme připojit do docker kontejneru kde beží Synapse odkud budeme přes příkaz register_new_matrix_user přidávat uživatele.

docker exec -it synapse /bin/bash

register_new_matrix_user -c /data/homeserver.yaml http://127.0.0.1:8008

Příkaz vás následně navede co vyplnit.

V tomto bodě nám už vše běží a máme vytvořeného prvního uživatele. Pokud se přes prohlížeč podíváte na http://<ip-adresa-vaseho-stroje>:8008 uvidíte že Matrix server běži.

Určitě se nechceme vždy připojovat na http://<ip-adresa-vaseho-stroje>:8008. To by bylo poněkud nepohodlné a pravděpodobně by to fungovalo jen v lokální síti. Ještě bychom mohli přesměrovat porty na router, ale to je prašť jako uhoď.

Lepší bude použít doménu jako matrix.nasedomena.eu a samozřejmě https protokol, aby naše data po internetu nelítala jen tak.

Bude to chtít zařídit několik věcí.

• Je potřeba mít veřejnou statickou IP.
• Koupit nějakou doménu.
• Vyřídit si certifikát. Například přes službu Let's Encrypt.
• Zprovoznit reverzní proxy, která bude zpracovávat příchozí požadavky. Pro tento článek použijeme webový server Nginx jako reverzní proxy. Jak zprovoznit Nginx jako reverzní proxy najdete v článku na tomto webu.

Budeme chtít používat https://matrix.nasedomena.eu a https://element.nasedomena.eu.

Pro element.nasedomena.eu bude konfigurační soubor pro Nginx vypadat nějak takhle.

 server {
    listen 80;
    server_name element.nasedomena.eu;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;

    server_name element.nasedomena.eu;

    ssl on;
    ssl_certificate /etc/letsencrypt/live/nasedomena.eu/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/nasedomena.eu/privkey.pem; # managed by Certbot

    location / {
        proxy_pass http://192.168.1.111:80;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_cache_bypass $http_upgrade;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

Veškerý nešifrovaný provoz směrující na element.nasedomena.eu bude přesměrován na šifrovaný.

Pro samotný Matrix server je nutné do konfigurace přidat ještě pár věcí.

server {
    listen 80;
    server_name matrix.nasedomena.eu;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    listen 8448 ssl http2 default_server;
    listen [::]:8448 ssl http2 default_server;

    server_name matrix.nasedomena.eu;

    ssl on;
    ssl_certificate /etc/letsencrypt/live/nasedomena.eu/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/nasedomena.eu/privkey.pem; # managed by Certbot

     location /.well-known/matrix/client {
                return 200 '{"m.server": {"base_url": "matrix.nasedomena.eu:443"}}';
                default_type application/json;
                add_header Access-Control-Allow-Origin *;
        }

    location /.well-known/matrix/server {
                default_type application/json;
                add_header Access-Control-Allow-Origin *;
                return 200 '{"m.server":"matrix.nasedomena.eu:443"}';
        }

    location / {
        proxy_pass http://192.168.1.111:8008;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_cache_bypass $http_upgrade;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

Jestli máme všechno dobře nakonfigurováno, můžeme zkusit https://element.nasedomena.eu. Poběží tu webový klient pro Matrix. Budeme muset upravit domovský server na náš matrix.nasedomena.eu, protože v základu je tam nastavený matrix.org. Poté se můžeme přihlásit jako uživatel, kterého jsme vytvořili v jednom z předchozích kroků.

K připojení můžete samozřejmě využít jakéhokoliv klienta Matrixu. Přidejte další další uživatele pomocí kroků výše a můžete začít komunikovat naprosto soukromě. Komunikace s dalšími uživateli v rámci Fediverse je také možná. Samotný Synapse jde různě nakonfigurovat. Můžete například povolit registraci uživatelů přes klienty a další možnosti. Konfigurace Synapse ale není náplní tohoto článku.

The post Self hosted Matrix server first appeared on Hard Wired.