Meta infra

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

Ja dorzucam propozycję Proxmoxa + kontenerów LXC, w miarę możliwości na każdą usługę osobnego. Nie twierdzę, że to rozwiązanie jest lepsze, może jest nawet gorsze, ale znam je najlepiej.

Natomiast mocno się moim zdaniem nie sugerujcie, bo raczej nie będę miał czasu pomagać w ustawianiu tego, więc wybierzcie, co dla Was będzie najwygodniejsze. Jak będę chciał dorzucić jakąś usługę, to najwyżej dopytam, jak to się robi, albo poproszę o pomoc.

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

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

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

Tu pojawia się magiczne słowo “konteneryzacja”. Choć zapewni to niższy poziom bezpieczeństwa, ale IMHO wystarczający.

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ść.

Ja bym powiedział, że zwiększy. Człowiek będzie mógł dostać do zabawy pusty kontener, który nie wiele będzie w możliwościach grzebania ustępował VMce i sobie tam będzie mógł się bawić. Można nawet stawiać kontenery w kontenerach.

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ą?

To zależy.

Docker działa mniej więcej tak jak opisałeś - jedna apka w kontenerze i do widzenia. Teoretycznie można robić inaczej, ale większość osób tworzących kontenery Dockera, tak do tego podchodzi z powodu bezpieczeństwa, minimalizacji rzeczy, które mogą się popsuć i pewnie innych przyczyn.

Jeśli kilka aplikacji musi ze sobą współgrać, to często pakuje się je do jednego kontenera np. Apache + PHP + MySQL + strona, która potrzebuje serwera LAMP, albo serwer IMAP i SMTP.

Nie wiem jak większość osób używa kontenerów LXC, ale ja to robię tak, że mam jeden, który jest de facto czystą instalacją Debiana + parę ustawień, które i tak bym chciał powielić i gdy potrzebuję wgrać jakąś apkę, to go klonuję i tam ją wgrywam. Staram się wgrywać jedną na kontener, ale jeśli i tak apki muszą mieć do siebie pełen dostęp, to czasem wgrywam ich kilka.

Na takim kontenerze LXC mogę robić prawie wszystko, co na VM. Jedynymi ograniczeniami, na jakie czasem trafiam, to brak możliwości modyfikowania parametrów jądra dla konkretnego kontenera. (może na uprzywilejowanych kontenerach się da? nie sprawdzałem)

Do zabawy można dawać komuś taki czysty kontener, a gdy będzie chciał coś wgrać “produkcyjnie”, to wtedy można się bawić w separację na więcej kontenerów.

Koszt czasowy i koszt zasobów przy stawianiu kolejnego kontenera jest niewielki. Można też od razu dawać kilka kontenerów do zabawy.

Nie dostrzegam, gdzie w tym wszystkim jest mniej swobody niż w wykorzystywaniu VM.

1 polubienie

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

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

Tak, da się, choć w jedynym przypadku w jakim miałem z tym do czynienia, to wydajność była niska, ale pewnie był to jakiś błąd konfiguracji.