Meta infra

Dyskusje o HSŁ
1

scenariusz: dostajemy serwer od hswaw. co dalej?

Scenariusz 1: stawiamy k8s i migrujemy usługi na k8s. Zaletą tego rozwiązania jest to, że na k8s możemy ustawić jakieś credentiale i osoby niedoświadczone z k8s nie będą musiały się bać, że wywalą jakieś kluczowe usługi.

Wady: no właśnie… Ile mamy osób doświadczonych z k8s w hsie? Ja osobiście nigdy się k8s nie tykałem, nie wiem do końca jak działa i musiałbym spędzić trochę czasu na jego naukę. Nie mówię nie: odkładam ten temat od dawna i z chęcią nauczę się k8s, ale nie wiem czy będzie na to czas kiedy będziemy już mieli ten mityczny serwer.

No i z tego powodu, że dużo osób po prostu chce się uczyć k8s, może nam się zrobić podobny syf co teraz na vmce. Osobiście nie jest to dla mnie problem, ale pojawiają się takie opinie, że zarządzanie naszymi hehe usługami staje się problematyczne, dla osób, które nie ogarniają tak dobrze tego bałaganu co osoby uruchamiający rzeczy na vmce.

Scenariusz 2: dokku. Dokku to taki open source klon heroku. Opiera się na nginxie (do reverse proxy) i dockerze do uruchamiania aplikacji. Aplikacje deployuje się robiąc push gitem na remote na serwerze z dokku. Zalety:

  • łatwo się deployuje nowe rzeczy (git push i elo)
  • możnaby zautomatyzować w końcu deploye, np samo aktualizujący się at po wrzuceniu taga na githubie
  • nie trzeba się tym za bardzo przejmować
  • ma fajny plugin do letsencrypt
  • wystarczyło by backupować tylko bazy danych

Wada, która nas dotyczy to fakt, że każdy user z rootem może wywalić nam dowolną usługę, ale to samo jest terez na vmce i jakoś to się często nie działo.

Scenariusz 3: dokku (albo cos innego co znamy) na infre, która ma po prostu działać: np forum, codi a k8s do eksperymentów. I w momencie kiedy będziemy się czuli komfortowo z k8s i wyrobimy sobie jakieś minimalne praktyki to można wtedy przejść na k8s jeśli będzie potrzeba. To jest mój ulubiony scenariusz.

To pewnie nie jedyne opcje, które powinniśmy rozważać. Macie jakieś inne pomysły? Znacie jakieś inne technologie, które by ułatwiły nam zarządzanie i deploy infrastrukturą w hsie? Piszcie ;>

pozdro
thinkofher

3

Wydaje mi się, że na poziomie samego serwera powinniśmy pójść w wirtualizację, i podzielić to na kilka środowisk: osobno produkcja (ma działać, nie hackujemy / tzn. można, ale nie na tym środowisku, tam wystawiamy daną rzecz, jak już będzie działająca, w miarę przetestowana i z ogarniętą konfiguracją, która będzie jakoś zoptymalizowana i zabezpieczona), osobno środowisko do zabawy, osobno to, o co tak prosi zarząd, czyli osobna VM-ka do rzeczy tajnych, na którą wjazd będą mieć tylko osoby z zarządu. Oczywiście może się zdarzyć, że jakaś bardziej kobylasta czy niestandardowa rzecz będzie wymagać osobnej VM-ki (lub komuś będzie zależeć na indywidualnej w jakimś konkretnym celu), wtedy też taką będzie można wykreować.

A co na tych VM-kach ma być – Kubernetesy, Dokku, czy goły Docker, jak na obecnej VM-ce – to już nie wiem, bo się nie znam. Choć chętnie się nauczę.

Na początek tak czy siak trzeba będzie chyba tam przenieść całą aktualną VM-kę, i potem stopniowo migrować z niej usługi do tej docelowej formy, jakąkolwiek sobie wybierzemy.

Sugeruję też przyjąć jakieś zasady co do dokumentowania tego, co stawiamy oraz całego setupu, ale to planuję poruszyć w jeszcze osobnym wątku.

2 polubienia
4

osobna vmka na rzeczy tajne dla zarzadu? wydaje mi się to trochę marnowaniem zasobów. rzeczy tajne to głównie dokumenty z danymi członków. je trzymamy na google drive teraz. osobna vmka specjalnie na dokumenty to chyba troche overkill w tym momencie naszej działalności.

1 polubienie
5

Jacek coś wspominał o migracji rzeczy, które trzyma u siebie na kompie, w stylu ten ksiengowy (program)…

Inna rzecz, że pojawiły się głosy, że ta maszyna jest za słaba, żeby iść na niej w wirtualizację. Ja się nie znam, nie umiem w ogóle w skalowanie serwerów.

Z drugiej strony chciałbym mieć taki rozdział na przestrzeń, którą można bezpiecznie się bawić i ją psuć, i przestrzeń, która da gwarancję stabilnego działania…

Zawsze do labowania można jeszcze odpalić coś w siedzibie.

No i pojawia się pytanie, co z LDAP-em. Jak mamy go używać do uwierzytelniania maszyn w spejsie, to trochę głupio pchać to uwierzytelnianie tunelem przez Internet do maszyny w HS-Waw… Inna rzecz, że tak czy siak czy to w jedną, czy w drugą stronę raczej będzie trzeba tak robić. No i tak czy siak, wypadałoby, by korzystał z tej samej bazy użytkowników, co aktualnie używane SSO, co tak czy siak wymusi komunikację na tej linii.

1 polubienie
7

Nie miałem dotąd za bardzo do czynienia z konteneryzacją, niemniej obawiam się, że to ograniczy wolność labowania i zabaw. Samo środowisko do uruchamiania kontenerów będzie musiało być stabilne i nie będzie można w nim za bardzo grzebać.

No ale od biedy są jeszcze te serwery w spejsie, a do labowania one nie muszą chodzić 24/7.

W każdym razie – jeśli to możliwe i nie zeżre nam zasobów na tyle, że i tak odpalenie jednej usługi (lub kilku w VM-kach) nam je kompletnie zawali, to byłbym za wirtualizacją. Jak w racjonalny sposób nie będzie się dało, to trudno. Pytanie, co z tym LDAP-em, ale najpierw trzeba to wylabować i wytestować, a widzicie, jaki sam mam do tego zapał (rzeczywistość jest taka, że po pracy mam trochę dosyć jakiegokolwiek grzebania w komputerach).

Według mnie:

  1. trzeba skończyć z ekscentrycznymi zasadami typu trzymanie środowisk wystawiających usługi, z których korzystają ludzie, w katalogach domowych użytkowników,
  2. trzeba dobrze udokumentować, jak z tego serwera korzystamy.

Nie mówię, by wprowadzać nie wiadomo jaki rygor – tylko proste i krótkie zasady, tak by było wiadomo, co do czego jest i z czym co można robić.

Brak dokumentacji prowadzi do nieporozumień i scysji… A brak spisanych zasad – o czym zresztą nawet alxd ostrzegał – do formowania się niepisanych zasad, które stają się wiedzą tajemną i niweczą inkluzywność.

9

Ja jakoś nie do końca te kontenery “czuję”. To nie tak, że założenie jest takie, że w pojedynczym kontenerze masz uruchamiać pojedynczą aplikację, a jak masz system korzystający z kilku (np. aplikacja i baza danych), to z założenia powinieneś te komponenty uruchamiać w osobnych kontenerach i komunikować się siecią IP wystawianą przez narzędzie do konteneryzacji? A uruchamiać “co się chce” w pojedynczym kontenerze niby się da, ale nie jest to zgodne ze sztuką?

11

fajny pomysł z tym lxc, ale czy w tym da sie odpalić dockera? to jest domyślny sposób odpalania aplikacji teraz u nas na vmce

12

To brzmi jak odpowiedź: https://stackoverflow.com/a/25885682/1091116

14

Podbijam temat, bo jest aktualny. Na ten moment mamy na VMce proxmoxa, gdzie jedyne IP jakie mamy dostaje bezpośrednio zmigrowana VMka.

Główny problem do rozwiązania jaki widzę to znalezienie softu a’la Phabricator które pomogłoby nam organizować różnego rodzaju działania: kanban board z dyskusjami i możliwością tworzenia grup ad hoc. Do tego jakiś kalendarz. Mam wrażenie że bardzo by nam się to w spejsie przydało. Phabricator niestety już nie jest utrzymywany, ale jest ten fork:

https://we.phorge.it/

Alternatywą jest Owncloud / Nextcloud (daje radę) oraz Redmine (testowałem, ni chuja tego u nas nie widzę). Opinie?

Oczywiście główny wątek, tj. w jaki sposób będziemy używać serwera, dalej uważam za aktualny.

15

Propsuję Nexcloud. Jest łatwy w utrzymaniu i konfiguracji, i ma dużo addonów do wszystkiego.

1 polubienie
16

Ok, zanim zaczniemy hostować takie rzeczy jak owncloud albo phorge.it powinniśmy ogarnąć naszą vmkę, która służy do wszystkiego.

Na podstawie moich ostatnich doświadczeń z nginx, wireguardem, dockerem itp proponuję następujące rozwiązanie:

  1. VMka z reverse proxy, wireguardem i firewallem (codename: pointer) i dnsem do wireguarda (dnsmasq) - jedyna vmka wystawiona na świat. Będzie odpalała nginx + hostowała wireguarda. Ewentualnie haproxy do rzeczy, których nie da się zrobić nginxem (np: irc, xmpp czy coś).
  2. VMka z serwisami takimi jak np: forum, at, matterbridge, pad. (codename: borzoi). Wystawia różne porty na lokalną sieć a nginx na pointerze proxuje je na świat z https.
  3. Opcjonalnie: VMka w owncloudem (codename: akita). Nie wiem jak bardzo zasobożerny jest owncloud, ale wydaje mi się, że dobrze by było to mieć na osobnej vmce.
  4. Opcjonalnie: VMka z bazami danych i cache, np: PostgreSQL albo Redis (codename: hokkaido). Jak mamy już proxmoxa to możemy odseparować warstwę storage od warstwy serwisowej.

Każda vmka miałaby swoją własną stronę, dostępną tylko w tunelu wireguard, z krótkim opisem co się na niej znajduje :), dostępną pod adresem: $codename.hs-ldz.pl.

Plusy:

  • przy pomocy wireguarda i pointera możemy łatwo wystawiać maszyny ze spejsu na świat
  • niski prób wejścia osób z zewnątrz. mógłbym przygotować tutorial i template configów do nginxa tak, żeby każdy mógł sobie coś wystawić. dużo materiałów w sieci jak konfigurować nginxa i dobra dokumentacja.
  • możemy postawić dodatkową vmke z dokku, robić proxy na wildcard *.dokku.hs-ldz.pl i dać opcje hostowania rzeczy jak na heroku.
  • mało magii

Minusy:

  • mało magii?
  • wyobrażam sobie, że niektórzy nie chcą babrać się w nginxie

pointer potrzebowałby z 2 - 4 GB pamięci. borzoi’owi pewnie wystarczy trochę więcej niż miała nasza vmka na hswaw. Nie wiem ile by potrzebował owncloud na akita i bazy danych na hokkaido.

Co sądzicie o takim rozwiązaniu? Spokojnie mogę pokonfigurować i administrować pointer’a. Potrzebowałbym pomocy z przeportowaniem rzeczy na borzoi’u. Należałoby ubić traefika i wystawiać kontenery na lokalną sieć na proxmoxie (da się tak?). Każdy kontener na inny port i reverse proxować to pointer’em.

ps: powymyślałem nazwy, ale nic nie narzucam, po prostu lubię wymyślać nazwy
ps 2: borzoi’a nie musimy stawiać od nowa, moglibyśmy przerobić obecną vmke

17

Nie chcę zbyt pospiesznie zbywać Twojego pomysłu, ale nie masz wrażenia że zarówno setup jak i utrzymywanie go pochłonie masę godzin?

Moja wizja (wydaje mi się że już o tym gadałem z @pmysl) jest taka żeby zrobić dwa klony tej starej VMki, z jednej wywalić infrę i zostawić samą “piaskownicę”, z drugiej wywalić użytkowników razem z ich /home i zrobić tam tylko infrę. Plus ogarnąć jak dodawać ręczne regułki do traefika, żeby przesyłał ruch pod konkretne VMki np po ipv6.

18

Ja bym zrobił tak, że tę obecną VM-kę trzymałbym tak długo, jak się z niej wszystkiego nie przemigruje, i po prostu sukcesywnie migrował z niej rzeczy tak, by były “po nowemu” (czymkolwiek to “nowe” miałoby nie być). Nie będziemy mieć na to żadnego ograniczenia czasowego… A będziemy mieć fajny, i używalny setup, którym będzie się dało zarządzać.

Na pewno potrzebujemy:

  • architektury poprzez którą dałoby się bardziej solidnie zarządzić “produkcyjnymi” usługami, istotnymi dla funkcjonowania spejsu (np. forum, pad)
  • VM-ki takiej typowo sandbox, gdzie każdy dostawałby konto i mógł robić co chce i wystawiać w formie kontenera, co chce
  • możliwości wystawiania VM-ek członkom na żądanie (oczywiście w granicach rozsądku i dostępności zasobów, tu już to musiałoby tak czy siak przez admina przechodzić), gdy ktoś chce porobić coś, na co kontener nie wystarczy
  • no i mowa była też o VM-ce zarządowej z rzeczami “prywatnymi”
19

Gdyby pomógł mi ktoś migrować rzeczy z obecnej vmki to setup zająłbym w najgorszym wypadku jeden wieczór. Administrowanie polegałoby na aktualizacji certyfikatów ssl i dodawaniu nowych członków do wireguarda.

traefik nie ogarnie nam innych usecasów niż http i https chyba. a jak będziemy trzymać proxy na tej samej maszynie co usługi to szybko zrobi nam się syf. dochodzi jeszcze taki scenariusz, że np ktoś nie chce odpalać swojego projektu przez dockera i wtedy traefik też niezbyt jest mu potrzeby.

żeby zrobić https://static.hs-ldz.pl do mediów do matterbridge musiałem odpalić w kontenerze nginxa albo caddy :smiley:

20

Ja Ci chętnie pomogę. Możemy nawet ogarnąć to razem w spejsie i sprawdzić czy to faktycznie będzie jeden wieczór ;D

1 polubienie
21

To ja też bym wbił i dołączył :slight_smile:

22

@pmysl @kpc dla mnie gitara. Możemy się umówić i to ogarnąć. Chyba każdy dzień w tym tygodniu byłby dla mnie spoko po 18, oprócz środy bo wtedy mamy spotkanie organizacyjne zarządu. W planach jest do 19, więc jakby ktoś chciał w środę to po 19.